home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-04-20 | 319.3 KB | 9,915 lines |
-
-
-
-
-
-
- Network Working Group R. Stine, Editor
- Request for Comments: 1147 SPARTA, Inc.
- FYI: 2 April 1990
-
-
- FYI on a Network Management Tool Catalog:
- Tools for Monitoring and Debugging TCP/IP Internets
- and Interconnected Devices
-
-
- Status of this Memo
-
- The goal of this FYI memo is to provide practical informa-
- tion to site administrators and network managers. This memo
- provides information for the Internet community. It does
- not specify any standard. It is not a statement of IAB pol-
- icy or recommendations. Comments, critiques, and new or
- updated tool descriptions are welcome, and should be sent to
- Robert Stine, at stine@sparta.com, or to the NOCTools work-
- ing group, at noctools@merit.edu.
-
- Distribution of this memo is unlimited.
-
- 1. Introduction
-
- This catalog contains descriptions of several tools avail-
- able to assist network managers in debugging and maintaining
- TCP/IP internets and interconnected communications
- resources. Entries in the catalog tell what a tool does,
- how it works, and how it can be obtained.
-
- The NOCTools Working Group of the Internet Engineering Task
- Force (IETF) compiled this catalog in 1989. Future editions
- will be produced as IETF members become aware of tools that
- should be included, and of deficiencies or inaccuracies.
- Developing an edition oriented to the OSI protocol suite is
- also contemplated.
-
- The tools described in this catalog are in no way endorsed
- by the IETF. For the most part, we have neither evaluated
- the tools in this catalog, nor validated their descriptions.
- Most of the descriptions of commercial tools have been pro-
- vided by vendors. Caveat Emptor.
-
- 1.1 Purpose
-
- The practice of re-inventing the wheel seems endemic to the
- field of data communications. The primary goal of this
-
-
-
- IETF NOCTools Working Group [Page 1]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
- document is to fight that tendency in a small but useful
- way. By listing the capabilities of some of the available
- network management tools, we hope to pool and share
- knowledge and experience. Another goal of this catalog is
- to show those new in the field what can be done to manage
- internet sites. A network management tutorial at the end of
- the document is of further assistance in this area.
- Finally, by omission, this catalog points out the network
- management tools that are needed, but do not yet exist.
-
- There are other sources of information on available network
- management tools. Both the DDN Protocol Implementation and
- Vendors Guide and the DATAPRO series on data communications
- and LANs are particularly comprehensive and informative.
- The DDN Protocol Implementation and Vendors Guide addresses
- a wide range of internet management topics, including
- evaluations of protocol implementations and network
- analyzers.* The DATAPRO volumes, though expensive (check
- your local university or technical libraries!), are good
- surveys of available commercial products for network manage-
- ment. DATAPRO also includes tutorials, market analyses,
- product evaluations, and predictions on technology trends.
-
- 1.2 Scope
-
- The tools described in this document are used for managing
- the network resources, LANs, and devices that are commonly
- interconnected by TCP/IP internets. This document is not,
- however, a "how to" manual on network management. While it
- includes a tutorial, the coverage is much too brief and gen-
- eral to serve as a sole source: a great deal of further
- study is required of aspiring network managers. Neither is
- this catalog is an operations manual for particular tools.
- Each individual tool entry is brief, and emphasizes the uses
- to which a tool can be put. A tool's documentation, which
- in some cases runs to hundreds of pages, should be consulted
- for assistance in its installation and operation.
-
- 1.3 Overview
-
- Section 1 describes the purpose, scope, and organization of
- this catalog.
-
- Section 2 lists and explains the standard keywords used in
- _________________________
- * Instructions for obtaining the DDN Protocol Guide are
- given in Section 7 of the appendix.
-
-
-
-
- IETF NOCTools Working Group [Page 2]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
- the tool descriptions. The keywords can be used as a sub-
- ject index into the catalog.
-
- Section 3, the main body of the catalog, contains the
- entries describing network management tools. The tool
- entries in Section 3 are presented in alphabetical order, by
- tool name. The tool descriptions all follow a standard for-
- mat, described in the introduction to Section 3.
-
- Following the catalog, there is an appendix that contains a
- tutorial on the goals and practice of network management.
-
- 1.4 Acknowledgements
-
- The compilation and editing of this catalog was sponsored by
- the Defense Communications Engineering Center (DCEC), con-
- tract DCA100-89-C-0001. The effort grew out of an initial
- task to survey current internet management tools. The cata-
- log is largely, however, the result of volunteer labor on
- the part of the NOCTools Working Group, the User Services
- Working Group, and many others. Without these volunteer
- contributions, the catalog would not exist. The support
- from the Internet community for this endeavor has been
- extremely gratifying.
-
- Several individuals made especially notable contributions.
- Mike Patton, Paul Holbrook, Mark Fedor and Gary Malkin were
- particularly helpful in composition and editorial review,
- while Dave Crocker provided essential guidance and
- encouragement. Bob Enger was active from the first with the
- gut work of chairing the Working Group and building the
- catalog. Phill Gross helped to christen the NOCTools Work-
- ing Group, to define its scope and goals, and to establish
- its role in the IETF. Mike Little contributed the formative
- idea of enhancing and publicizing the management tool survey
- through IETF participation.
-
- Responsibility for any deficiencies and errors remains, of
- course, with the editor.
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 3]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
- 2. Keywords
-
- This catalog uses "keywords" for terse characterizations of
- the tools. Keywords are abbreviated attributes of a tool or
- its use. To allow cross-comparison of tools, uniform key-
- word definitions have been developed, and are given below.
- Following the definitions, there is an index of catalog
- entries by keyword.
-
- 2.1 Keyword Definitions
-
- The keywords are always listed in a prefined order, sorted
- first by the general category into which they fall, and then
- alphabetically. The categories that have been defined for
- management tool keywords are:
-
- o+ the general management area to which a tool
- relates or a tool's functional role;
-
- o+ the network resources or components that are
- managed;
-
- o+ the mechanisms or methods a tool uses to perform
- its functions;
-
- o+ the operating system and hardware environment of a
- tool; and
-
- o+ the characteristics of a tool as a hardware pro-
- duct or software release.
-
-
- The keywords used to describe the general management area or
- functional role of a tool are:
-
- Alarm
- a reporting/logging tool that can trigger on specific
- events within a network.
-
- Analyzer
- a traffic monitor that reconstructs and interprets pro-
- tocol messages that span several packets.
-
- Benchmark
- a tool used to evaluate the performance of network com-
- ponents.
-
-
-
-
-
- IETF NOCTools Working Group [Page 4]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- Control
- a tool that can change the state or status of a remote
- network resource.
-
- Debugger
- a tool that by generating arbitrary packets and moni-
- toring traffic, can drive a remote network component to
- various states and record its responses.
-
- Generator
- a traffic generation tool.
-
- Manager
- a distributed network management system or system com-
- ponent.
-
- Map
- a tool that can discover and report a system's topology
- or configuration.
-
- Reference
- a tool for documenting MIB structure or system confi-
- guration.
-
- Routing
- a packet route discovery tool.
-
- Security
- a tool for analyzing or reducing threats to security.
-
- Status
- a tool that remotely tracks the status of network com-
- ponents.
-
- Traffic
- a tool that monitors packet flow.
-
-
- The keywords used to identify the network resources or com-
- ponents that a tool manages are:
-
- Bridge
- a tool for controlling or monitoring LAN bridges.
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 5]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- CHAOS
- a tool for controlling or monitoring implementations of
- the CHAOS protocol suite or network components that use
- it.
-
- DECnet
- a tool for controlling or monitoring implementations of
- the DECnet protocol suite or network components that
- use it.
-
- DNS
- a Domain Name System debugging tool.
-
- Ethernet
- a tool for controlling or monitoring network components
- on ethernet LANs.
-
- FDDI
- a tool for controlling or monitoring network components
- on FDDI LANs or WANs.
-
- IP
- a tool for controlling or monitoring implementations of
- the TCP/IP protocol suite or network components that
- use it.
-
- OSI
- a tool for controlling or monitoring implementations of
- the OSI protocol suite or network components that use
- it.
-
- NFS
- a Network File System debugging tool.
-
- Ring
- a tool for controlling or monitoring network components
- on Token Ring LANs.
-
- SMTP
- an SMTP debugging tool.
-
- Star
- a tool for controlling or monitoring network components
- on StarLANs.
-
-
- The keywords used to describe a tool's mechanism are:
-
-
-
- IETF NOCTools Working Group [Page 6]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- Curses
- a tool that uses the "curses" tty interface package.
-
- Eavesdrop
- a tool that silently monitors communications media
- (e.g., by putting an ethernet interface into "promiscu-
- ous" mode).
-
- NMS
- the tool is a component of or queries a Network Manage-
- ment System.
-
- Ping
- a tool that sends packet probes such as ICMP echo mes-
- sages; to help distinguish tools, we do not consider
- NMS queries or protocol spoofing (see below) as probes.
-
- Proprietary
- a distributed tool that uses proprietary communications
- techniques to link its components.
-
- SNMP
- a network management system or component based on SNMP,
- the Simple Network Management Protocol.
-
- Spoof
- a tool that tests operation of remote protocol modules
- by peer-level message exchange.
-
- X
- a tool that uses X-Windows.
-
-
- The keywords used to describe a tool's operating environment
- are:
-
- DOS
- a tool that runs under MS-DOS.
-
- HP
- a tool that runs on Hewlett-Packard systems.
-
- Macintosh
- a tool that runs on Macintosh personal computers.
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 7]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- Standalone
- an integrated hardware/software tool that requires only
- a network interface for operation.
-
- UNIX
- a tool that runs under 4.xBSD UNIX or related OS.
-
- VMS
- a tool that runs under DEC's VMS operating system.
-
-
- The keywords used to describe a tool's characteristics as a
- hardware or software acquisition are:
-
- Free
- a tool is available at no charge, though other restric-
- tions may apply (tools that are part of an OS distribu-
- tion but not otherwise available are not listed as
- "free").
-
- Library
- a tool packaged with either an Application Programming
- Interface (API) or object-level subroutines that may be
- loaded with programs.
-
- Sourcelib
- a collection of source code (subroutines) upon which
- developers may construct other tools.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 8]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
- 2.2 Tools Indexed by Keywords
-
- Following is an index of catalog entries sorted by keyword.
- This index can be used to locate the tools with a particular
- attribute: tools are listed under each keyword that charac-
- terizes them. The keywords and the subordinate lists of
- tools under them are in alphabetical order.
-
- In the interest of brevity, some liberties have been taken
- with tool names. Capitalization of the names is as speci-
- fied by the tool developers or distributers. Note that
- parenthetical roman numerals following a tool's name are not
- actually part of the name. The use of roman numerals to
- differentiate tools with the same name is explained in the
- introduction of Section 3.
-
- alarm bridge
- CMIP Library ConnectVIEW
- EtherMeter decaddrs
- LanProbe NMC
- LANWatch proxyd
- NETMON (III) Snmp Libraries
- osilog snmpd
- SERAG
- sma
- Snmp Libraries CHAOS
- snmptrapd LANWatch
- SpiderMonitor map
- Unisys NCC
- WIN/MGT Station
- xnetmon (I) control
- XNETMON (II) CMIP Library
- ConnectVIEW
- NETMON (III)
- analyzer NMC
- LANWatch proxyd
- Sniffer Snmp Libraries
- SpiderMonitor snmpset
- TokenVIEW
- Unisys NCC
- benchmark WIN/MGT Station
- hammer XNETMON (II)
- nhfsstone
- SPIMS
- spray
- TTCP
- Unisys NCC
-
-
-
-
- IETF NOCTools Working Group [Page 9]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- curses DOS
- Internet Rover Comp. Security Checklist
- net_monitor ConnectVIEW
- nfswatch hammer
- osimon hopcheck
- snmpperfmon LAN Patrol
- LANWatch
- netmon (I)
- debugger NETMON (III)
- SPIMS netwatch
- OverVIEW
- ping
- DECnet Snmp Libraries
- decaddrs snmpd (II)
- LANWatch TokenVIEW
- NETMON (III) XNETMON (II)
- net_monitor xnetperfmon
- NMC
- Sniffer
- Snmp Libraries eavesdrop
- SpiderMonitor ENTM
- XNETMON (II) etherfind
- xnetperfmon EtherView
- LAN Patrol
- LanProbe
- DNS LANWatch
- DiG NETMON (II)
- LANWatch netwatch
- netmon (I) nfswatch
- nslookup NNStat
- OSITRACE
- Sniffer
- SpiderMonitor
- Tcplogger
- TRPT
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 10]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- ethernet free
- arp arp
- ConnectVIEW CMIP Library
- ENTM CMU SNMP
- etherfind DiG
- etherhostprobe ENTM
- EtherMeter etherhostprobe
- EtherView hammer
- LAN Patrol hopcheck
- LanProbe HyperMIB
- LANWatch Internet Rover
- map map
- NETMON (III) netmon (I)
- netwatch NETMON (II)
- Network Integrator netstat
- nfswatch netwatch
- NMC net_monitor
- NNStat nfswatch
- proxyd nhfsstone
- SERAG NNStat
- Sniffer NPRV
- Snmp Libraries nslookup
- snmpd (II) osilog
- SpiderMonitor osimic
- tcpdump osimon
- Unisys NCC OSITRACE
- WIN/MGT Station ping
- XNETMON (II) query
- xnetperfmon sma
- SNMP Kit
- tcpdump
- FDDI tcplogger
- Unisys NCC traceroute
- TRPT
- TTCP
-
-
- generator
- hammer
- nhfsstone
- ping
- Sniffer
- SpiderMonitor
- spray
- TTCP
- Unisys NCC
-
-
-
-
- IETF NOCTools Working Group [Page 11]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- HP IP
- xup arp
- CMU SNMP
- Dual Manager
- ENTM
- etherfind
- etherhostprobe
- EtherView
- getone
- hammer
- hopcheck
- Internet Rover
- LANWatch
- map
- Netlabs CMOT Agent
- Netlabs SNMP Agent
- netmon (I)
- NETMON (II)
- NETMON (III)
- netstat
- netwatch
- net_monitor
- nfswatch
- NMC
- NNStat
- NPRV
- OverVIEW
- ping
- proxyd
- query
- SERAG
- Sniffer
- SNMP Kit
- Snmp Libraries
- snmpask
- snmpd (I)
- snmpd (II)
- snmplookup
- snmpperfmon
- snmppoll
- snmpquery
- snmproute
- snmpset
- snmpsrc
- snmpstat
- snmptrapd
- snmpwatch
-
-
-
- IETF NOCTools Working Group [Page 12]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
- snmpxbar
- snmpxconn manager
- snmpxmon CMIP Library
- snmpxperf CMU SNMP
- snmpxperfmon ConnectVIEW
- snmpxrtmetric decaddrs
- SpiderMonitor Dual Manager
- SPIMS getone
- spray LanProbe
- Tcpdump map
- Tcplogger Netlabs CMOT Agent
- Traceroute Netlabs SNMP Agent
- TRPT NETMON (III)
- TTCP NMC
- Unisys NCC NNStat
- WIN/MGT Station osilog
- xnetmon (I) osimic
- XNETMON (II) osimon
- xnetperfmon OverVIEW
- sma
- SNMP Kit
- library Snmp Libraries
- CMIP Library snmpask
- Dual Manager snmpd (I)
- LANWatch snmpd (II)
- proxyd snmplookup
- WIN/MGT Station snmpperfmon
- snmppoll
- snmpquery
- Macintosh snmproute
- HyperMIB snmpsrc
- snmpset
- snmpstat
- snmptrapd
- snmpwatch
- snmpxbar
- snmpxconn
- snmpxmon
- snmpxperf
- snmpxperfmon
- snmpxrtmetric
- TokenVIEW
- Unisys NCC
- WIN/MGT Station
- xnetmon (I)
- XNETMON (II)
- xnetperfmon
-
-
-
-
- IETF NOCTools Working Group [Page 13]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- map NMS
- decaddrs CMU SNMP
- etherhostprobe ConnectVIEW
- EtherMeter decaddrs
- LanProbe Dual Manager
- map EtherMeter
- NETMON (III) getone
- Network Integrator LanProbe
- NPRV map
- Snmp Libraries Netlabs CMOT Agent
- snmpxconn Netlabs SNMP Agent
- snmpxmon NETMON (III)
- Unisys NCC NMC
- xnetmon (I) NNStat
- XNETMON (II) OverVIEW
- proxyd
- SERAG
- NFS SNMP Kit
- etherfind Snmp Libraries
- EtherView snmpask
- nfswatch snmpd (I)
- nhfsstone snmpd (II)
- Sniffer snmplookup
- tcpdump snmpperfmon
- snmppoll
- snmpquery
- snmproute
- snmpset
- snmpsrc
- snmpstat
- snmptrapd
- snmpwatch
- snmpxbar
- snmpxconn
- snmpxmon
- snmpxperf
- snmpxperfmon
- snmpxrtmetric
- TokenVIEW
- Unisys NCC
- WIN/MGT Station
- xnetmon (I)
- XNETMON (II)
- xnetperfmon
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 14]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- OSI ring
- CMIP Library ConnectVIEW
- Dual Manager LANWatch
- LANWatch map
- Netlabs CMOT Agent NETMON (III)
- NETMON (III) netwatch
- osilog proxyd
- osimic Sniffer
- osimon Snmp Libraries
- OSITRACE snmpd (II)
- sma TokenVIEW
- Sniffer XNETMON (II)
- Snmp Libraries xnetperfmon
- SpiderMonitor
- SPIMS
- XNETMON (II) routing
- xnetperfmon arp
- ConnectVIEW
- decaddrs
- ping etherhostprobe
- etherhostprobe getone
- hopcheck hopcheck
- Internet Rover NETMON (III)
- map netstat
- netmon (I) net_monitor
- net_monitor NMC
- NPRV NPRV
- ping query
- spray Snmp Libraries
- traceroute snmproute
- TTCP snmpsrc
- Unisys NCC snmpxrtmetric
- xup traceroute
- WIN/MGT Station
- XNETMON (II)
- proprietary
- ConnectVIEW
- EtherMeter security
- LanProbe Comp. Security Checklist
- SERAG ConnectVIEW
- TokenVIEW Dual Manager
- LAN Patrol
- SERAG
- reference XNETMON (II)
- HyperMIB
- Unisys NCC
-
-
-
-
- IETF NOCTools Working Group [Page 15]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- SMTP sourcelib
- Internet Rover CMIP Library
- LANWatch CMU SNMP
- mconnect HyperMIB
- Sniffer Internet Rover
- LANWatch
- map
- SNMP NETMON (III)
- CMU SNMP net_monitor
- decaddrs proxyd
- Dual Manager SNMP Kit
- getone Snmp Libraries
- map Snmpd (II)
- Netlabs SNMP Agent SpiderMonitor
- NETMON (III) XNETMON (II)
- NMC xnetperfmon
- OverVIEW
- proxyd
- SNMP Kit spoof
- Snmp Libraries DiG
- snmpask Internet Rover
- snmpd (I) mconnect
- snmpd (II) nhfsstone
- snmplookup nslookup
- snmpperfmon query
- snmppoll SPIMS
- snmpquery
- snmproute
- snmpset standalone
- snmpsrc EtherMeter
- snmpstat Sniffer
- snmptrapd SpiderMonitor
- snmpwatch
- snmpxbar
- snmpxconn star
- snmpxmon LAN Patrol
- snmpxperf LANWatch
- snmpxperfmon map
- snmpxrtmetric NETMON (III)
- Unisys NCC proxyd
- WIN/MGT Station Sniffer
- xnetmon (I) Snmp Libraries
- XNETMON (II) snmpd (II)
- xnetperfmon XNETMON (II)
- xnetperfmon
-
-
-
-
-
- IETF NOCTools Working Group [Page 16]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- status traffic
- CMIP Library ENTM
- CMU SNMP etherfind
- ConnectVIEW EtherMeter
- DiG EtherView
- Dual Manager LAN Patrol
- getone LanProbe
- Internet Rover LANWatch
- LanProbe NETMON (II)
- mconnect netwatch
- Netlabs CMOT Agent Network Integrator
- Netlabs SNMP Agent nfswatch
- netmon (I) NMC
- net_monitor NNStat
- NMC osimon
- NNStat OSITRACE
- NPRV Sniffer
- nslookup snmpxperfmon
- osimic SpiderMonitor
- osimon tcpdump
- OverVIEW tcplogger
- ping TRPT
- proxyd Unisys NCC
- sma WIN/MGT Station
- SNMP Kit
- Snmp Libraries
- snmpask
- snmpd (I)
- snmpd (II)
- snmplookup
- snmpperfmon
- snmppoll
- snmpquery
- snmpstat
- snmpwatch
- snmpxbar
- snmpxconn
- snmpxmon
- snmpxperf
- snmpxperfmon
- TokenVIEW
- Unisys NCC
- WIN/MGT Station
- xnetmon (I)
- XNETMON (II)
- xnetperfmon
- xup
-
-
-
- IETF NOCTools Working Group [Page 17]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
- snmpxbar
- UNIX snmpxconn
- arp snmpxmon
- CMIP Library snmpxperf
- CMU SNMP snmpxperfmon
- decaddrs snmpxrtmetric
- DiG SPIMS
- Dual Manager spray
- etherfind tcpdump
- etherhostprobe tcplogger
- EtherView traceroute
- getone TRPT
- Internet Rover TTCP
- map Unisys NCC
- mconnect WIN/MGT Station
- NETMON (II) xnetmon (I)
- netstat XNETMON (II)
- Network Integrator xnetperfmon
- net_monitor
- nfswatch
- nhfsstone VMS
- NMC arp
- NNStat ENTM
- nslookup netstat
- osilog net_monitor
- osimic NPRV
- osimon nslookup
- OSITRACE ping
- ping Snmp Libraries
- proxyd tcpdump
- query traceroute
- SERAG TTCP
- sma XNETMON (II)
- SNMP Kit xnetperfmon
- Snmp Libraries
- snmpask
- snmpd (I)
- snmpd (II)
- snmplookup
- snmpperfmon
- snmppoll
- snmpquery
- snmproute
- snmpset
- snmpsrc
- snmpstat
- snmptrapd
- snmpwatch
-
-
-
- IETF NOCTools Working Group [Page 18]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
-
- X
- Dual Manager
- map
- snmpxbar
- snmpxconn
- snmpxmon
- snmpxperf
- snmpxperfmon
- snmpxrtmetric
- WIN/MGT Station
- XNETMON (II)
- xnetperfmon
- xup
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 19]
-
- RFC 1147 FYI: Network Management Tool Catalog April 1990
-
-
- 3. Tool Descriptions
-
- This section is a collection of brief descriptions of tools
- for managing TCP/IP internets. These entries are in alpha-
- betical order, by tool name.
-
- The entries all follow a standard format. Immediately after
- the NAME of a tool are its associated KEYWORDS. Keywords
- are terse descriptions of the purposes or attributes of a
- tool. A more detailed description of a tool's purpose and
- characteristics is given in the ABSTRACT section. The
- MECHANISM section describes how a tool works. In CAVEATS,
- warnings about tool use are given. In BUGS, known bugs or
- bug-report procedures are given. LIMITATIONS describes the
- boundaries of a tool's capabilities. HARDWARE REQUIRED and
- SOFTWARE REQUIRED relate the operational environment a tool
- needs. Finally, in AVAILABILITY, pointers to vendors,
- online repositories, or other sources for a tool are given.
-
- We deal with the problem of tool-name clashes -- different
- tools that have the same name -- by appending parenthetical
- roman numerals to the names. For example, BYU, MITRE, and
- SNMP Research each submitted a description of a tool called
- "NETMON." These tools were independently developed, are
- functionally different, run in different environments, and
- are no more related than Richard Burton the 19th century
- explorer and Richard Burton the 20th century actor. BYU's
- tool "NETMON" is listed as "NETMON (I)," MITRE's as "NETMON
- (II)," and the tool from SNMP Research as "NETMON (III)."
-
- The parenthetical roman numerals reveal only the order in
- which the catalog editor received the tool descriptions.
- They should not be construed to indicate any sort of prefer-
- ence, priority, or rights to a tool name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 20]
-
- Internet Tool Catalog ARP
-
-
- NAME
- arp
-
- KEYWORDS
- routing; ethernet, IP; UNIX, VMS; free.
-
- ABSTRACT
- Arp displays and can modify the internet-to-ethernet
- address translations tables used by ARP, the address
- resolution protocol.
-
- MECHANISM
- The arp program accesses operating system memory to
- read the ARP data structures.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- Only the super user can modify ARP entries.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS, or VMS.
-
- AVAILABILITY
- Available via anonymous FTP from uunet.uu.net, in
- directory bsd-sources/src/etc. Available with 4.xBSD
- UNIX and related operating systems. For VMS, available
- as part of TGV MultiNet IP software package, as well as
- Wollongong's WIN/TCP.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 21]
-
- Internet Tool Catalog CMIP LIBRARY
-
-
- NAME
- CMIP Library
-
- KEYWORDS
- alarm, control, manager, status; OSI; UNIX; free,
- library, sourcelib.
-
- ABSTRACT
- The CMIP Library implements the functionality of the
- Common Management Information Service/Protocol as in
- the documents ISO DP 9595-2/9596-2 of March 1988. It
- can act as a building block for the construction of
- CMIP-based agent and manager applications.
-
- MECHANISM
- The CMIP library uses ISO ROS, ACSE and ASN.1 presenta-
- tion, as implemented in ISODE, to provide its service.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- The M-CREATE, M-DELETE and M-ACTION protocol primitives
- are not implemented in this version.
-
- HARDWARE REQUIRED
- Developed on Sun3, tested on Sun3 and VAXStation.
-
- SOFTWARE REQUIRED
- The ISODE protocol suite, BSD UNIX.
-
- AVAILABILITY
- The CMIP library and related management tools built
- upon it, known as OSIMIS (OSI Management Information
- Service), are publicly available from University Col-
- lege London, England via FTP and FTAM. To obtain
- information regarding a copy send email to
- gknight@ac.ucl.cs.uk or call +44 1 380 7366.
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 22]
-
- Internet Tool Catalog CMU SNMP
-
-
- NAME
- The CMU SNMP Distribution
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX; free, sourcelib.
-
- ABSTRACT
- The CMU SNMP Distribution includes source code for an
- SNMP agent, several SNMP client applications, an ASN.1
- library, and supporting documentation.
-
- The agent compiles into about 10 KB of 68000 code. The
- distribution includes a full agent that runs on a
- Kinetics FastPath2/3/4, and is built into the KIP
- appletalk/ethernet gateway. The machine independent
- portions of this agent also run on CMU's IBM PC/AT
- based router.
-
- The applications are designed to be useful in the real
- world. Information is collected and presented in a
- useful format and is suitable for everyday status moni-
- toring. Input and output are interpreted symbolically.
- The tools can be used without referencing the RFCs.
-
- MECHANISM
- SNMP.
-
- CAVEATS
- None.
-
- BUGS
- None reported. Send bug reports to
- sw0l+snmp@andrew.cmu.edu. ("sw0l" is "ess double-you
- zero ell.")
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- The KIP gateway agent runs on a Kinetics FastPath2/3/4.
- Otherwise, no restrictions.
-
- SOFTWARE REQUIRED
- The code was written with efficiency and portability in
- mind. The applications compile and run on the follow-
- ing systems: IBM PC/RT running ACIS Release 3, Sun3/50
- running SUNOS 3.5, and the DEC microVax running Ultrix
- 2.2. They are expected to run on any system with a
-
-
-
- IETF NOCTools Working Group [Page 23]
-
- Internet Tool Catalog CMU SNMP
-
-
- Berkeley socket interface.
-
- AVAILABILITY
- This distribution is copyrighted by CMU, but may be
- used and sold without permission. Consult the copy-
- right notices for further information. The distribu-
- tion is available by anonymous FTP from the host
- lancaster.andrew.cmu.edu (128.2.13.21) as the files
- pub/cmu-snmp.9.tar, and pub/kip-snmp.9.tar. The former
- includes the libraries and the applications, and the
- latter is the KIP SNMP agent.
-
- Please direct questions, comments, and bug reports to
- sw0l+snmp@andrew.cmu.edu. ("sw0l" is "ess double-you
- zero ell.") If you pick up this package, please send a
- note to the above address, so that you may be notified
- of future enhancements/changes and additions to the set
- of applications (several are planned).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 24]
-
- Internet Tool Catalog COMPUTER SECURITY CHECKLIST
-
-
- NAME
- Computer Security Checklist
-
- KEYWORDS
- security; DOS.
-
- ABSTRACT
- This program consists of 858 computer security ques-
- tions divided up in thirteen sections. The program
- presents the questions to the user and records their
- responses. After answering the questions in one of the
- thirteen sections, the user can generate a report from
- the questions and the user's answers. The thirteen
- sections are: telecommunications security, physical
- access security, personnel security, systems develop-
- ment security, security awareness and training prac-
- tices, organizational and management security, data and
- program security, processing and operations security,
- ergonomics and error prevention, environmental secu-
- rity, and backup and recovery security.
-
- The questions are weighted as to their importance, and
- the report generator can sort the questions by weight.
- This way the most important issues can be tackled
- first.
-
- MECHANISM
- The questions are displayed on the screen and the user
- is prompted for a single keystroke reply. When the end
- of one of the thirteen sections is reached, the answers
- are written to a disk file. The question file and the
- answer file are merged to create the report file.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- DOS operating system.
-
-
-
-
- IETF NOCTools Working Group [Page 25]
-
- Internet Tool Catalog COMPUTER SECURITY CHECKLIST
-
-
-
- AVAILABILITY
- A commercial product available from:
- C.D., Ltd.
- P.O. Box 58363
- Seattle, WA 98138
- (206) 243-8700
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 26]
-
- Internet Tool Catalog CONNECTVIEW
-
-
- NAME
- ConnectVIEW
-
- KEYWORDS
- control, manager, routing, security, status; bridge,
- ethernet, ring; NMS, proprietary; DOS.
-
- ABSTRACT
- The ConnectVIEW Network Management System consists of
- various software managers that control and manage Hal-
- ley System's internets made of of ConnectLAN 100 ether-
- net and ConnectLAN 200 Token Ring Brouters. The
- management software provides an icon-based graphical
- network display with real-time monitoring and report-
- ing, along with configuration, fault, performance and
- security management functions for managing ConnectLAN
- brouters. A Planning function is also provided that
- allows users to draw their networks.
-
- MECHANISM
- Proprietary.
-
- CAVEATS
- The ConnectVIEW software must be running under Micro-
- soft Windows, preferably on a dedicated management sta-
- tion. There is, however, no degradation of LAN
- throughput.
-
- BUGS
- None known.
-
- LIMITATIONS
- Currently works only with Halley System's products.
-
- HARDWARE REQUIRED
- Requires a PC/AT compatible, with 640KB RAM, EGA
- adapter and monitor, keyboard, mouse, and ethernet
- adapter.
-
- SOFTWARE REQUIRED
- MSDOS 3.3 or higher. Microsoft Windows/286 version
- 2.1.
-
- AVAILABILITY
- Commercially available from:
- Halley Systems, Inc.
- 2730 Orchard Parkway
- San Jose, CA 95134
-
-
-
- IETF NOCTools Working Group [Page 27]
-
- Internet Tool Catalog CONNECTVIEW
-
-
- NAME
- decaddrs, decaroute, decnroute, xnsroutes, bridgetab
-
- KEYWORDS
- manager, map, routing; bridge, DECnet; NMS, SNMP; UNIX.
-
- ABSTRACT
- These commands display private MIB information from
- Wellfleet systems. They retrieve and format for
- display values of one or several MIB variables from the
- Wellfleet Communications private enterprise MIB, using
- the SNMP (RFC1098). In particular these tools are used
- to examine the non-IP modules (DECnet, XNS, and Bridg-
- ing) of a Wellfleet system.
-
- Decaddrs displays the DECnet configuration of a
- Wellfleet system acting as a DECnet router, showing the
- static parameters associated with each DECnet inter-
- face. Decaroute and decnroute display the DECnet
- inter-area and intra-area routing tables (that is area
- routes and node routes). Xnsroutes displays routes
- known to a Wellfleet system acting as an XNS router.
- Bridgetab displays the bridge forwarding table with the
- disposition of traffic arriving from or directed to
- each station known to the Wellfleet bridge module. All
- these commands take an IP address as the argument and
- can specify an SNMP community for the retrieval. One
- SNMP query is performed for each row of the table.
- Note that the Wellfleet system must be operating as an
- IP router for the SNMP to be accessible.
-
- MECHANISM
- Management information is exchanged by use of SNMP.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- Distributed and supported for Sun 3 systems.
-
- SOFTWARE REQUIRED
- Distributed and supported for SunOS 3.5 and 4.x.
-
-
-
- IETF NOCTools Working Group [Page 28]
-
- Internet Tool Catalog DECADDRS, DECAROUTE, et al.
-
-
-
- AVAILABILITY
- Commercial product of:
- Wellfleet Communications, Inc.
- 12 DeAngelo Drive
- Bedford, MA 01730-2204
- (617) 275-2400
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 29]
-
- Internet Tool Catalog DIG
-
-
- NAME
- DiG
-
- KEYWORDS
- status; DNS; spoof; UNIX; free.
-
- ABSTRACT
- DiG (domain information groper), is a command line tool
- which queries DNS servers in either an interactive or a
- batch mode. It was developed to be more
- convenient/flexible than nslookup for gathering perfor-
- mance data and testing DNS servers.
-
- MECHANISM
- Dig is built on a slightly modified version of the bind
- resolver (release 4.8).
-
- CAVEATS
- none.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX.
-
- AVAILABILITY
- DiG is available via anonymous FTP from venera.isi.edu
- in pub/dig.1.0.tar.Z.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 30]
-
- Internet Tool Catalog DUAL MANAGER
-
-
- NAME
- Dual Manager
-
- KEYWORDS
- alarm, control, manager, map, security, status; IP,
- OSI; NMS, SNMP, X; UNIX; library.
-
- ABSTRACT
- Netlabs' Dual Manager provides management of TCP/IP
- networks using both SNMP and CMOT protocols. Such
- management can be initiated either through the X-
- Windows user interface (both Motif and Openlook), or
- through OSI Network Management (CMIP) commands. The
- Dual Manager provides for configuration, fault, secu-
- rity and performance management. It provides extensive
- map management features, including scanned maps in the
- background. It provides simple mechanisms to extend
- the MIB and assign specific lists of objects to
- specific network elements, thereby providing for the
- management of all vendors' specific MIB extensions. It
- provides an optional relational DBMS for storing and
- retrieving MIB and alarm information. Finally, the
- Dual Manager is an open platform, in that it provides
- several Application Programming Interfaces (APIs) for
- users to extend the functionality of the Dual Manager.
-
- The Dual Manager is expected to work as a TCP/IP
- "branch manager" under DEC's EMA, AT&T's UNMA and other
- OSI-conformant enterprise management architectures.
-
- MECHANISM
- The Netlabs Dual Manager supports the control and moni-
- toring of network resources by use of both CMOT and
- SNMP message exchanges.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- Runs on Sun/3 and Sun/4s.
-
-
-
-
-
- IETF NOCTools Working Group [Page 31]
-
- Internet Tool Catalog DUAL MANAGER
-
-
-
- SOFTWARE REQUIRED
- Available on System V or SCO Open Desktop environments.
- Uses X-Windows for the user interface.
-
- AVAILABILITY
- Commercially available from:
- Netlabs Inc
- 11693 Chenault Street Ste 348
- Los Angeles CA 90049
- (213) 476-4070
- lam@netlabs.com (Anne Lam)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 32]
-
- Internet Tool Catalog ENTM
-
-
- NAME
- ENTM -- Ethernet Traffic Monitor
-
- KEYWORDS
- traffic; ethernet, IP; eavesdrop; VMS; free.
-
- ABSTRACT
- ENTM is a screen-oriented utility that runs under
- VAX/VMS. It monitors local ethernet traffic and
- displays either a real time or cumulative, histogram
- showing a percent breakdown of traffic by ethernet pro-
- tocol type. The information in the display can be
- reported based on packet count or byte count. The per-
- cent of broadcast, multicast and approximate lost pack-
- ets is reported as well. The screen display is updated
- every three seconds. Additionally, a real time, slid-
- ing history window may be displayed showing ethernet
- traffic patterns for the last five minutes.
-
- ENTM can also report IP traffic statistics by packet
- count or byte count. The IP histograms reflect infor-
- mation collected at the TCP and UDP port level, includ-
- ing ICMP type/code combinations. Both the ethernet and
- IP histograms may be sorted by ASCII protocol/port name
- or by percent-value. All screen displays can be saved
- in a file for printing later.
-
- MECHANISM
- This utility simply places the ethernet controller in
- promiscuous mode and monitors the local area network
- traffic. It preallocates 10 receive buffers and
- attempts to keep 22 reads pending on the ethernet dev-
- ice.
-
- CAVEATS
- Placing the ethernet controller in promiscuous mode may
- severly slow down a VAX system. Depending on the speed
- of the VAX system and the amount of traffic on the lo-
- cal ethernet, a large amount of CPU time may be spent
- on the Interrupt Stack. Running this code on any pro-
- duction system during operational hours is discouraged.
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 33]
-
- Internet Tool Catalog ENTM
-
-
-
- BUGS
- Due to a bug in the VAX/VMS ethernet/802 device driver,
- IEEE 802 format packets may not always be detected. A
- simple test is performed to "guess" which packets are
- in IEEE 802 format (DSAP equal to SSAP). Thus, some
- DSAP/SSAP pairs may be reported as an ethernet type,
- while valid ethernet types may be reported as IEEE 802
- packets.
-
- In some hardware configurations, placing an ethernet
- controller in promiscuous mode with automatic-restart
- enabled will hang the controller. Our VAX 8650 hangs
- running this code, while our uVAX IIs and uVAX IIIs do
- not.
-
- Please report any additional bugs to the author at:
- Allen Sturtevant
- National Magnetic Fusion Energy Computer Center
- Lawrence Livermore National Laboratory
- P.O. Box 808; L-561
- Livermore, CA 94550
- Phone : (415) 422-8266
- E-Mail: sturtevant@ccc.nmfecc.gov
-
- LIMITATIONS
- The user is required to have PHY_IO, TMPMBX and NETMBX
- privileges. When activated, the program first checks
- that the user process as enough quotas remaining
- (BYTLM, BIOLM, ASTLM and PAGFLQUO) to successfully run
- the program without entering into an involuntary wait
- state. Some quotas require a fairly generous setting.
-
- The contents of IEEE 802 packets are not examined.
- Only the presence of IEEE 802 packets on the wire is
- reported.
-
- The count of lost packets is approximated. If, after
- each read completes on the ethernet device, the utility
- detects that it has no reads pending on that device,
- the lost packet counter is incremented by one.
-
- When the total number of bytes processed exceeds
- 7fffffff hex, all counters are automatically reset to
- zero.
-
- HARDWARE REQUIRED
- A DEC ethernet controller.
-
-
-
- IETF NOCTools Working Group [Page 34]
-
- Internet Tool Catalog ENTM
-
-
-
- SOFTWARE REQUIRED
- VAX/VMS version V5.1+.
-
- AVAILABILITY
- For executables only, FTP to the ANONYMOUS account
- (password GUEST) on CCC.NMFECC.GOV and GET the follow-
- ing files:
-
- [ANONYMOUS.PROGRAMS.ENTM]ENTM.DOC (ASCII text)
- [ANONYMOUS.PROGRAMS.ENTM]ENTM.EXE (binary)
- [ANONYMOUS.PROGRAMS.ENTM]EN_TYPES.DAT (ASCII text)
- [ANONYMOUS.PROGRAMS.ENTM]IP_TYPES.DAT (ASCII text)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 35]
-
- Internet Tool Catalog ETHERFIND
-
-
- NAME
- etherfind
-
- KEYWORDS
- traffic; ethernet, IP, NFS; eavesdrop; UNIX.
-
- ABSTRACT
- Etherfind examines the packets that traverse a network
- interface, and outputs a text file describing the
- traffic. In the file, a single line of text describes
- a single packet: it contains values such as protocol
- type, length, source, and destination. Etherfind can
- print out all packet traffic on the ethernet, or
- traffic for the local host. Further packet filtering
- can be done on the basis of protocol: IP, ARP, RARP,
- ICMP, UDP, ND, TCP, and filtering can also be done
- based on the source, destination addresses as well as
- TCP and UDP port numbers.
-
- MECHANISM
- In usual operations, and by default, etherfind puts the
- interface in promiscuous mode. In 4.3BSD UNIX and
- related OSs, it uses a Network Interface Tap (NIT) to
- obtain a copy of traffic on an ethernet interface.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- Minimal protocol information is printed. Can only be
- run by the super user. The syntax is painful.
-
- HARDWARE REQUIRED
- Ethernet.
-
- SOFTWARE REQUIRED
- SunOS.
-
- AVAILABILITY
- Executable included in Sun OS "Networking Tools and
- Programs" software installation option.
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 36]
-
- Internet Tool Catalog ETHERHOSTPROBE
-
-
- NAME
- etherhostprobe
-
- KEYWORDS
- map, routing; ethernet, IP; ping; UNIX; free.
-
- ABSTRACT
- Output list of hosts on an ethernet that respond to IP
- ARP. Produces a list in the following format:
-
- 08:00:20:01:96:62 128.18.4.114 apptek4
- 08:00:20:00:02:fe 128.18.4.115 apptek5
- 08:00:20:00:57:6a 128.18.4.116 apptek6
- 08:00:20:00:65:34 128.18.4.117 apptek7
- 08:00:20:06:58:6f 128.18.4.118 apptek8
- 08:00:20:00:03:4f 128.18.4.119 apptek9
-
- The first column is the ethernet address, the second
- the IP address, and the third is the hostname (which is
- omitted if the name could not be found via gethost-
- byaddr). A starting and ending IP address may be
- specified on the command line, which will limit the
- search.
-
- MECHANISM
- Etherhostprobe sends a UDP packet to the ``echo'' port,
- then looks in the kernel's ARP cache for the
- corresponding address entry. Explicit response (or
- lack of same) to the UDP packet is ignored. The cache
- will be checked up to four times at one-quarter-second
- intervals. Note that this allows the program to be run
- by a user with no special privileges.
-
- CAVEATS
- Etherhostprobe will fill the kernel's ARP cache with
- possibly useless entries, possibly causing delays to
- programs foolishly attempting to accomplish real work.
-
- Etherhostprobe causes -lots- of ARPs to be generated,
- possibly fooling network monitoring software (or peo-
- ple) into concluding that something is horribly broken.
-
- Etherhostprobe spends up to one second looking for each
- possible address. Thus, exhaustively searching a
- class-C network will take about four minutes, and
- exhaustively searching a class-B network will take
- about 18 hours. Exhaustively searching a class-A net-
- work will take the better part of a year, so don't even
-
-
-
- IETF NOCTools Working Group [Page 37]
-
- Internet Tool Catalog ETHERHOSTPROBE
-
-
- think about it.
-
- Etherhostprobe will be fooled by gateways that imple-
- ment proxy ARP; every possible address on the proxy-
- ARPed subnet will be listed with the gateway's ethernet
- address.
-
- BUGS
- None known.
-
- LIMITATIONS
- If a given machine is not running IP ARP at the time
- that it is probed, it will be considered nonexistent.
- In particular, if a given machine is down at the time
- that it is probed . . .
-
- All hosts being probed must be on the same (possibly
- bridged) ethernet.
-
- HARDWARE REQUIRED
- No restrictions, but see below.
-
- SOFTWARE REQUIRED
- Runs on SunOS 3.5, and possibly elsewhere. The major
- non-standard portion of code is ``tx_arp.c'', which
- reads the kernel's ARP cache.
-
- AVAILABILITY
- Copyrighted, but freely distributed. Available via
- anonymous FTP from spam.itstd.sri.com (128.18.10.1).
- From pub directory, file EHP.1 for etherhostprobe, and
- files IPF.1 and IPF.2 for ipForwarding.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 38]
-
- Internet Tool Catalog ETHERMETER
-
-
- NAME
- EtherMeter (tm), model LANB/150
-
- KEYWORDS
- alarm, map, traffic; ethernet; NMS, proprietary; stan-
- dalone.
-
- ABSTRACT
- The Network Applications Technology (NAT) EtherMeter
- product is a dedicated ethernet traffic monitor that
- provides statistics on the ethernet segment to which it
- is attached. The EtherMeter reports three major kinds
- of statistics. For good packets, it reports the total
- number of good packets seen on the segment, the number
- of multicast and broadcast packets, and the total
- number of bytes in all packets seen. For packets with
- errors, it reports the number of CRC errors, short
- packets, oversize packets, and alignment errors. It
- also reports the distribution of packet by type, and
- the number of protocols seen on the segment. A count
- of transmit collisions is reported. Peak and current
- ethernet utilization rates are also reported, etc.
- Alarms can be set for utilization rate, packet rate,
- total error count, and delta error.
-
- The EtherMeter reports the statistics to a Network
- Management Station (NMS), also available from NAT, via
- IP/UDP datagrams, so that the meters can be monitored
- through routers. The NMS displays graphical and/or
- textual information, and EtherMeter icons turn colors
- to indicate status. Alarms can be set, and if the lev-
- els are exceeded an audible alarm is generated on the
- NMS, and the EtherMeter icon changes from green to yel-
- low on the network map.
-
- MECHANISM
- The EtherMeter is a self-contained board that can
- either be plugged into a PC/AT bus for power or
- installed in a small stand-alone enclosure. The board
- can be obtained with either a 10BASE5 thick ethernet
- transceiver cable connector, or a 10BASE2 thin ethernet
- BNC connector.
-
- CAVEATS
- The EtherMeter is primarily a passive device whose only
- impact on the network will come from the monitoring
- packets sent to the NMS. The EtherMeter is assigned an
- IP address for communication with the NMS.
-
-
-
- IETF NOCTools Working Group [Page 39]
-
- Internet Tool Catalog ETHERMETER
-
-
-
- BUGS
- None known.
-
- LIMITATIONS
- Proprietary protocol currently in use. The company has
- stated its intention to develop SNMP for the EtherMeter
- product in the first half of 1990. Currently the NMS
- does not keep log files. This limitation is ack-
- nowledged, and plans are underway to add ASCII log file
- capability to the NMS.
-
- HARDWARE REQUIRED
- An EtherMeter board and a PC/AT bus to plug it into, or
- a stand-alone enclosure with power supply (available
- from NAT). A Network Management Station and its
- software is required as well, to fully interact with
- the EtherMeter devices.
-
- SOFTWARE REQUIRED
- The EtherMeter software is included in ROM on the dev-
- ice. The NMS software is bundled in with the NMS
- hardware.
-
- AVAILABILITY
- The EtherMeter device, stand-alone enclosure, and Net-
- work Management Station, are available commercially
- from:
-
- Network Application Technology, Inc.
- 21040 Homestead Road
- Cupertino, California 95014
- Phone: (408) 733-4530
- Fax: (408) 733-6478
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 40]
-
- Internet Tool Catalog ETHERVIEW
-
-
- NAME
- EtherView(tm)
-
- KEYWORDS
- traffic; ethernet, IP, NFS; eavesdrop; UNIX.
-
- ABSTRACT
- EtherView is a network monitoring tool which runs on
- Sun workstations and allows you to monitor your hetero-
- geneous internet network. It monitors all systems on
- the ethernet. It has three primary functions:
-
- Load Profile: It allows users to monitor the load on
- the ethernet over extended periods of time. The net-
- work administrator can use it to characterize load gen-
- erated by a node on the network, determine which sys-
- tems and applications generate how much of the load and
- how that load fluctuates over long periods of time.
-
- NFS Profile: It allows the network administrator to
- determine the load on NFS servers, the average response
- time NFS servers and the mix of NFS load on each of the
- servers. Users can use the data to benchmark different
- NFS servers, determine which servers are overloaded,
- deduce the number of clients that each server can sup-
- port and evaluate the effectiveness of NFS accelera-
- tors.
-
- Protocol Analyzer: Users can capture packets based on
- source, destination, application, protocol, bit pat-
- tern, packet size or a boolean filtering expression.
- It provides all standard features such as configurable
- buffer size, packet slicing and bit pattern based
- triggering criterion. It does automatic disassembly of
- NFS, TCP, UDP, IP, ICMP, ARP and RARP packets. Packets
- can be examined in any combination of summary, hex or
- detail format.
-
- MECHANISM
- EtherView uses the Sun's NIT interface to turn the eth-
- ernet interface into promiscuous mode to capture pack-
- ets. A high level process manages the interface and a
- low level process does the actual capturing and filter-
- ing. Shared memory is used to communicate between the
- two processes.
-
- BUGS
- None known.
-
-
-
- IETF NOCTools Working Group [Page 41]
-
- Internet Tool Catalog ETHERVIEW
-
-
-
- LIMITATIONS
- Because of limitations in Sun's NIT interface, Ether-
- View will not capture packets originating from the sys-
- tem where it is run.
-
- EtherView requires super-user privileges on the system
- where it is run.
-
- HARDWARE REQUIRED
- EtherView runs on all models of Sun-3, Sun-4 and Sun-
- 386i.
-
- SOFTWARE REQUIRED
- Sun-3 - SunOS 4.0.3. (SunOS 4.0 with NIT fixes).
- Sun-4 - SunOS 4.0.
- Sun-386i - SunOS 4.0.
-
- Runs under SunView.
- Will run under X Windows in future.
-
- AVAILABILITY
- EtherView is copyrighted, commercial product of:
- Matrix Computer Systems, Inc.
- 7 1/2 Harris Road
- Nashua, NH 03062
-
- Tel: (603) 888-7790
- email: ...uunet!matrix!eview
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 42]
-
- Internet Tool Catalog GETONE, GETMANY, et al.
-
-
- NAME
- getone, getmany, getroute, getarp, getaddr, getif,
- getid.
-
- KEYWORDS
- manager, routing, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- These commands retrieve and format for display values
- of one or several MIB variables (RFC1066) using the
- SNMP (RFC1098). Getone and getmany retrieve arbitrary
- MIB variables; getroute, getarp, getaddr, and getif
- retrieve and display tabular information (routing
- tables, ARP table, interface configuration, etc.), and
- getid retrieves and displays system name, identifica-
- tion and boot time.
-
- Getone <target> <mibvariable> retrieves and displays
- the value of the designated MIB variable from the
- specified target system. The SNMP community name to be
- used for the retrieval can also be specified. Getmany
- works similarly for groups of MIB variables rather than
- individual values. The name of each variable, its
- value and its data type is displayed. Getroute returns
- information from the ipRoutingTable MIB structure,
- displaying the retrieved information in an accessible
- format. Getarp behaves similarly for the address
- translation table; getaddr for the ipAddressTable; and
- getif displays information from the interfaces table,
- supplemented with information from the ipAddressTable.
- Getid displays the system name, identification, ipFor-
- warding state, and the boot time and date. All take a
- system name or IP address as an argument and can
- specify an SNMP community for the retrieval. One SNMP
- query is performed for each row of the table.
-
- MECHANISM
- Queries SNMP agent(s).
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
-
-
-
- IETF NOCTools Working Group [Page 43]
-
- Internet Tool Catalog GETONE, GETMANY, et al.
-
-
-
- HARDWARE REQUIRED
- Distributed and supported for Sun 3 systems.
-
- SOFTWARE REQUIRED
- Distributed and supported for SunOS 3.5 and 4.x.
-
- AVAILABILITY
- Commercial product of:
- Wellfleet Communications, Inc.
- 12 DeAngelo Drive
- Bedford, MA 01730-2204
- (617) 275-2400
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 44]
-
- Internet Tool Catalog HAMMER & ANVIL
-
-
- NAME
- hammer & anvil
-
- KEYWORDS
- benchmark, generator; IP; DOS; free.
-
- ABSTRACT
- Hammer and anvil are the benchmarking programs for IP
- routers. Using these tools, gateways have been tested
- for per-packet delay, router-generated traffic over-
- head, maximum sustained throughput, etc.
-
- MECHANISM
- Tests are performed on a gateway in an isolated
- testbed. Hammer generates packets at controlled rates.
- It can set the length and interpacket interval of a
- packet stream. Anvil counts packet arrivals.
-
- CAVEATS
- Hammer should not be run on a live network.
-
- BUGS
- None reported.
-
- LIMITATIONS
- Early versions of hammer could not produce inter-packet
- intervals shorter than 55 usec.
-
- HARDWARE REQUIRED
- Hammer runs on a PC/AT or compatible, and anvil
- requires a PC or clone. Both use a Micom Interlan
- NI5210 for LAN interface.
-
- SOFTWARE REQUIRED
- MS-DOS.
-
- AVAILABILITY
- Hammer and anvil are copyrighted, though free. Copies
- are available from pub/eutil on husc6.harvard.edu.
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 45]
-
- Internet Tool Catalog HOPCHECK
-
-
- NAME
- hopcheck
-
- KEYWORDS
- routing; IP; ping; DOS; free.
-
- ABSTRACT
- Hopcheck is a tool that lists the gateways traversed by
- packets sent from the hopcheck-resident PC to a desti-
- nation. Hopcheck uses the same mechanism as traceroute
- but is for use on IBM PC compatibles that have ethernet
- connections. Hopcheck is part of a larger TCP/IP pack-
- age that is known as ka9q that is for use with packet
- radio. Ka9q can coexist on a PC with other TCP/IP
- packages such as FTP Inc's PC/TCP, but must be used
- independently of other packages. Ka9q was written by
- Phil Karn. Hopcheck was added by Katie Stevens,
- dkstevens@ucdavis.edu. Unlike traceroute, which
- requires a UNIX kernel mod, hopcheck will run on the
- standard, unmodified ka9q release.
-
- MECHANISM
- See the description in traceroute.
-
- CAVEATS
- See the description in traceroute.
-
- BUGS
- None known.
-
- LIMITATIONS
- Host table required. Does not work with domain name
- server or with IP address as the argument. This is
- mainly an inconvenience.
-
- HARDWARE REQUIRED
- IBM PC compatible with ethernet network interface card,
- though does not work with 3Com 505 board.
-
- SOFTWARE REQUIRED
- DOS.
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 46]
-
- Internet Tool Catalog HOPCHECK
-
-
-
- AVAILABILITY
- Free. On deposit at the National Center for Atmospher-
- ic Research. For access from UNIX, available via
- anonymous FTP from windom.ucar.edu, in directory "etc,"
- as hopcheck.tar.Z. For access directly from a PC,
- fetch nethop.exe and readme.hop; nethop.exe is execut-
- able. Also available via anonymous FTP at ucdavis.edu,
- in the nethopexe or nethopsrc suite of files in direc-
- tory "dist."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 47]
-
- Internet Tool Catalog HYPERMIB
-
-
- NAME
- HyperMIB
-
- KEYWORDS
- reference; Macintosh; free, sourcelib.
-
- ABSTRACT
- HyperMIB is a hypertext presentation of the MIB
- (RFC1066). The tree structure of the MIB is presented
- graphically, and the user traverses the tree by select-
- ing branches of the tree. When the MIB variables are
- displayed, selecting them causes a text window to
- appear and show the definition of that variable (using
- the actual text of the MIB document).
-
- MECHANISM
- The Apple Macintosh HyperCard utility is used. The
- actual text of the MIB document is read into scrollable
- text windows, and a string search is done on the vari-
- able selected. A person familiar with HyperCard pro-
- gramming could modify the program to suit their needs
- (such as to add the definitions for their company's
- private space).
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- This program only gives the definition of the MIB vari-
- ables. It cannot poll a node to find the value of the
- variables.
-
- HARDWARE REQUIRED
- Apple Macintosh computer with at least 1MByte of RAM.
-
- SOFTWARE REQUIRED
- Apple Macintosh operating system and HyperCard.
-
- AVAILABILITY
- This software may be copied and given away without
- charge. The files are available by anonymous FTP on
- CCC.NMFECC.GOV. The files are:
-
- [Anonymous.programs.HyperMIB]Hyper_MIB.help (ASCII text)
- [Anonymous.programs.HyperMIB]Hyper.MIB (binary)
-
-
-
- IETF NOCTools Working Group [Page 48]
-
- Internet Tool Catalog HYPERMIB
-
-
- [Anonymous.programs.HyperMIB]MIB.tree (binary)
-
- The software is also available for a nominal fee from:
-
- National Energy Software Center
- Argonne National Laboratory
- 9700 South Cass Avenue
- Argonne, Illinois 60439
- (312) 972-7250
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 49]
-
- Internet Tool Catalog INTERNET ROVER
-
-
- NAME
- Internet Rover
-
- KEYWORDS
- status; IP, SMTP; curses, ping, spoof; UNIX; free,
- sourcelib.
-
- ABSTRACT
- Internet Rover is a prototype network monitor that uses
- multiple protocol "modules" to test network functional-
- ity. This package consists of two primary pieces of
- code: the data collector and the problem display.
-
- There is one data collector that performs a series of
- network tests, and maintains a list of problems with
- the network. There can be many display processes all
- displaying the current list of problems which is useful
- in a multi-operator NOC.
-
- The display task uses curses, allowing many terminal
- types to display the problem file either locally or
- from a remote site. Full source is provided. The data
- collector is easily configured and extensible. Contri-
- butions such as additional protocol modules, and shell
- script extensions are welcome.
-
- MECHANISM
- A configuration file contains a list of nodes,
- addresses, NodeUp? protocol test (ping in most cases),
- and a list of further tests to be performed if the node
- is in fact up. Modules are included to test TELNET,
- FTP, and SMTP. If the configuration contains a test
- that isn't recognized, a generic test is assumed, and a
- filename is checked for existence. This way users can
- create scripts that create a file if there is a prob-
- lem, and the data collector simply checks the existence
- of that file to determine if there is problem.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 50]
-
- Internet Tool Catalog INTERNET ROVER
-
-
-
- LIMITATIONS
- This tools does not yet have the capability to perform
- actions based on the result of the test. Rather, it is
- intended for a multi-operator environment, and simply
- displays a list of what is wrong with the net.
-
- HARDWARE REQUIRED
- This software is known to run on Suns and IBM RTs.
-
- SOFTWARE REQUIRED
- Curses, 4.xBSD UNIX socket programming libraries, BSD
- ping.
-
- AVAILABILITY
- Full source available via anonymous FTP from merit.edu
- (35.1.1.42) in the ~ftp/pub/inetrover directory.
- Source and executables are public domain and can be
- freely distributed for non-commercial use. This pack-
- age is unsupported, but bug reports and fixes may be
- sent to: wbn@merit.edu.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 51]
-
- Internet Tool Catalog LAN PATROL
-
-
- NAME
- LAN Patrol
-
- KEYWORDS
- security, traffic; ethernet, star; eavesdrop; DOS.
-
- ABSTRACT
- LAN Patrol is a full-featured network analyzer that
- provides essential information for effective fault and
- performance management. It allows network managers to
- easily monitor user activity, find traffic overloads,
- plan for growth, test cable, uncover intruders, balance
- network services, and so on. LAN Patrol uses state of
- the art data collection techniques to monitor all
- activity on a network, giving an accurate picture of
- how it is performing.
-
- LAN Patrol's reports can be saved as ASCII files to
- disk, and imported into spreadsheet or database pro-
- grams for further analysis.
-
- MECHANISM
- The LAN Patrol interface driver programs a standard
- interface card to capture all traffic on a network seg-
- ment. The driver operates from the background of a
- standard PC, maintaining statistics for each station on
- the network. The information can be viewed on the PC's
- screen, or as a user-defined report output either to
- file or printer.
-
- CAVEATS
- None. Normal operation is completely passive, making
- LAN Patrol transparent to the network.
-
- BUGS
- None known.
-
- LIMITATIONS
- LAN Patrol can monitor up to 10,000 packets/sec on an
- AT class PC, and is limited to monitoring a maximum of
- 1024 stations for intervals of up to 30 days.
-
- Because LAN Patrol operates at the physical level, it
- will only see traffic for the segment on which it is
- installed; it cannot see traffic across bridges.
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 52]
-
- Internet Tool Catalog LAN PATROL
-
-
-
- HARDWARE REQUIRED
- Computer: IBM PC/XT/AT, PS/2 Model 30, or compatible.
- Requires 512K memory and a hard drive or double-sided
- disk drive.
-
- Display: Color or monochrome text. Color display
- allows color-coding of traffic information.
-
- Ethernet, StarLAN, LattisNet, or StarLAN 10 network
- interface card.
-
- SOFTWARE REQUIRED
- PC DOS, MS-DOS version 3.1 or greater.
-
- AVAILABILITY
- LAN Patrol many be purchased through network dealers,
- or directly from:
- Legend Software, Inc.
- Phone: (201) 227-8771
- FAX: (201) 906-1151
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 53]
-
- Internet Tool Catalog LANPROBE
-
-
- NAME
- LanProbe -- the HP 4990S LanProbe Distributed Analysis
- System.
-
- KEYWORDS
- alarm, manager, map, status, traffic; ethernet; eaves-
- drop, NMS; proprietary.
-
- ABSTRACT
- The LanProbe distributed monitoring system performs
- remote and local monitoring of ethernet LANs in a pro-
- tocol and vendor independent manner.
-
- LanProbe discovers each active node on a segment and
- displays it on a map with its adapter card vendor name,
- ethernet address, and IP address. Additional informa-
- tion about the nodes, such as equipment type and physi-
- cal location can be entered in to the data base by the
- user.
-
- When the NodeLocator option is used, data on the actual
- location of nodes is automatically entered and the map
- becomes an accurate representation of the physical lay-
- out of the segment. Thereafter when a new node is
- installed and becomes active, or when a node is moved
- or becomes inactive, the change is detected and shown
- on the map in real time. The system also provides the
- network manager with precise cable fault information
- displayed on the map.
-
- Traffic statistics are gathered and displayed and can
- be exported in (comma delimited) CSV format for further
- analysis. Alerts can be set on user defined thres-
- holds.
-
- Trace provides a remote protocol analyzer capability
- with decodes for common protocols.
-
- Significant events (like power failure, cable breaks,
- new node on network, broadcast IP source address seen,
- etc.) are tracked in a log that is uploaded to Pro-
- beView periodically.
-
- ProbeView generates reports that can be manipulated by
- MSDOS based word processors, spreadsheets, and DBMS.
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 54]
-
- Internet Tool Catalog LANPROBE
-
-
-
- MECHANISM
- The system consists of one or more LanProbe segment
- monitors and ProbeView software running under Microsoft
- Windows. The LanProbe segment monitor attaches to the
- end of an ethernet segment and monitors all traffic.
- Attachment can be direct to a thin or thick coax cable,
- or via an external transceiver to fiber optic or twist-
- ed pair cabling. Network data relating to the segment
- is transferred to a workstation running ProbeView via
- RS-232, ethernet, or a modem connection.
-
- ProbeView software, which runs on a PC/AT class works-
- tation, presents network information in graphical
- displays.
-
- The HP4992A NodeLocator option attaches to the opposite
- end of the cable from the HP4991A LanProbe segment mon-
- itor. It automatically locates the position of nodes
- on the ethernet networks using coaxial cabling schemes.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- HP 4991A LanProbe segment monitor
- HP 4992A NodeLocator (for optional capabilities)
- 80386 based PC capable of running MS-Windows
-
- SOFTWARE REQUIRED
- HP 4990A ProbeView
- MSDOS 3.0 or higher and Microsoft Windows/286 2.1.
-
- AVAILABILITY
- A commercial product available from:
- Hewlett-Packard Company
- P.O. Box 10301,
- Palo Alto, CA 94303-0890
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 55]
-
- Internet Tool Catalog LANWATCH
-
-
- NAME
- LANWatch
-
- KEYWORDS
- alarm, analyzer, traffic; CHAOS, DECnet, DNS, ethernet,
- IP, OSI, ring, SMTP, star; eavesdrop; DOS; library,
- sourcelib.
-
- ABSTRACT
- LANWatch 2.0 is an inexpensive, powerful and flexible
- network analyzer that runs under DOS on personal com-
- puters and requires no hardware modifications to either
- the host or the network. LANWatch is an invaluable
- tool for installing, troubleshooting, and monitoring
- local area networks, and for developing and debugging
- new protocols. Network managers using LANWatch can
- inspect network traffic patterns and packet errors to
- isolate performance problems and bottlenecks. Protocol
- developers can use LANWatch to inspect and verify
- proper protocol handling. Since LANWatch is a
- software-only package which installs easily in existing
- PCs, network technicians and field service engineers
- can carry LANWatch in their briefcase for convenient
- network analysis at remote sites.
-
- LANWatch has two operating modes: Display and Examine.
- In Display Mode, LANWatch traces network traffic by
- displaying captured packets in real time. Examine Mode
- allows you to scroll back through stored packets to
- inspect them in detail. To select a subset of packets
- for display, storage or retrieval, there is an exten-
- sive set of built-in filters. Using filters, LANWatch
- collects only packets of interest, saving the user from
- having to sort through all network traffic to isolate
- specific packets. The built-in filters include alarm,
- trigger, capture, load, save and search. They can be
- controlled separately to match on source or destination
- address, protocol, or packet contents at the hardware
- and transport layers. LANWatch also includes suffi-
- cient source code so users can modify the existing
- filters and parsers or add new ones.
-
- The LANWatch distribution includes executables and
- source for several post-processors: a TCP protocol
- analyzer, a node-by-node traffic analyzer and a dump
- file listing tool.
-
- MECHANISM
-
-
-
- IETF NOCTools Working Group [Page 56]
-
- Internet Tool Catalog LANWATCH
-
-
- Uses many common PC network interfaces by placing them
- in promiscuous mode and capturing traffic.
-
- CAVEATS
- Most PC network interfaces will not capture 100% of the
- traffic on a fully-loaded network (primarily missing
- back-to-back packets).
-
- BUGS
- None known.
-
- LIMITATIONS
- LANWatch can't analyze what it doesn't see (see
- Caveats).
-
- HARDWARE REQUIRED
- LANWatch requires a PC or PS/2 with a supported network
- interface card.
-
- SOFTWARE REQUIRED
- LANWatch runs in DOS. Modification of the supplied
- source code or creation of additional filters and
- parsers requires Microsoft C 5.1
-
- AVAILABILITY
- LANWatch is commercially available from FTP Software,
- Incorporated, 26 Princess Street, Wakefield, MA, 01880
- (617 246-0900).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 57]
-
- Internet Tool Catalog MAP
-
-
- NAME
- map -- Interactive Network Map
-
- KEYWORDS
- manager, map; CHAOS, ethernet, IP, ring, star; NMS,
- ping, SNMP, X; UNIX; free, sourcelib.
-
- ABSTRACT
- Map draws a map of network connectivity and allows
- interactive examination of information about various
- components including whether hosts can be reached over
- the network.
-
- The program is supplied with complete source and is
- written in a modular fashion to make addition of dif-
- ferent protocols stacks, displays, or hardcopy devices
- relatively easy. This is one of the reasons why the
- initial version supports at least two of each. Contri-
- butions of additional drivers in any of these areas
- will be welcome as well as porting to additional plat-
- forms.
-
- MECHANISM
- Net components are pinged by use of ICMP echo and,
- optionally, CHAOS status requests and SNMP "gets." The
- program initializes itself from static data stored in
- the file system and therefore does not need to access
- the network in order to get running (unless the static
- files are network mounted).
-
- CAVEATS
- As of publication, the tool is in beta release.
-
- BUGS
- Several minor nits, documented in distribution files.
- Bug discoveries should be reported by email to Bug-
- Map@LCS.MIT.Edu.
-
- LIMITATIONS
- See distribution file for an indepth discussion of sys-
- tem capabilities and potential.
-
- HARDWARE REQUIRED
- An X display is needed for interactive display of the
- map, non-graphical interaction is available in non-
- display mode. For hardcopy output a PostScript or Tek-
- tronix 4692 printer is required.
-
-
-
-
- IETF NOCTools Working Group [Page 58]
-
- Internet Tool Catalog MAP
-
-
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS. IP/ICMP is required;
- CHAOS/STATUS and SNMP can be used but are optional.
- X-Windows is required for interactive display of the
- map.
-
- AVAILABILITY
- As of publication, map is in beta release. To be added
- to the email forum that discusses the software, or to
- obtain individual files or instructions on getting the
- full current release, send a request to:
-
- MAP-Request@LCS.MIT.Edu.
-
- The program is Copyright MIT. It is available via
- anonymous FTP with a license making it free to use and
- distribute for non-commercial purposes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 59]
-
- Internet Tool Catalog MCONNECT
-
-
- NAME
- mconnect
-
- KEYWORDS
- status; SMTP; spoof; UNIX.
-
- ABSTRACT
- Mconnect allows an interactive session with a remote
- mailer. Mail delivery problems can be diagnosed by
- connecting to the remote mailer and issuing SMTP com-
- mands directly.
-
- MECHANISM
- Opens a TCP connection to remote SMTP on port 25. Pro-
- vides local line buffering and editing, which is the
- distinction between mconnect and a TELNET to port 25.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- Mconnect is not a large improvement over using a TELNET
- connection to port 25.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS.
-
- AVAILABILITY
- Available with 4.xBSD UNIX and related operating sys-
- tems.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 60]
-
- Internet Tool Catalog NETLABS CMOT AGENT
-
-
- NAME
- Netlabs CMOT Agent
-
- KEYWORDS
- manager, status; IP, OSI; NMS.
-
- ABSTRACT
- Netlabs' CMOT code debuted in Interop 89. The CMOT
- code comes with an Extensible MIB, which allows users
- to add new MIB variables. The code currently supports
- all the MIB variables in RFC 1095 via the data types in
- RFC 1065, as well as the emerging MIB-II, which is
- currently in experimental stage. The CMOT has been
- benchmarked at 100 Management Operations per Second
- (MOPS) for a 1-MIPS machine.
-
- MECHANISM
- The Netlabs CMOT agent supports the control and moni-
- toring of network resources by use of CMOT message
- exchanges.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- Portable to most hardware.
-
- SOFTWARE REQUIRED
- Portable to most operating systems.
-
- AVAILABILITY
- Commercially available from:
- Netlabs Inc
- 11693 Chenault Street Ste 348
- Los Angeles CA 90049
- (213) 476-4070
- lam@netlabs.com (Anne Lam)
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 61]
-
- Internet Tool Catalog NETLABS SNMP AGENT
-
-
- NAME
- Netlabs SNMP Agent.
-
- KEYWORDS
- manager, status; IP; NMS, SNMP.
-
- ABSTRACT
- Netlabs' SNMP code debuted in Interop 89, where it
- showed interoperation of the code with several imple-
- mentations on the show floor. The SNMP code comes with
- an Extensible MIB, which allows users to add new MIB
- variables. The code currently supports all the MIB
- variables in RFC 1066 via the data types in RFC 1065,
- as well as the emerging MIB-II, which is currently in
- experimental stage. The SNMP has been benchmarked at
- 200 Management Operations per Second (MOPS) for a 1-
- MIPS machine.
-
- MECHANISM
- The Netlabs SNMP agent supports the control and moni-
- toring of network resources by use of SNMP message
- exchanges.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- Portable to most hardware.
-
- SOFTWARE REQUIRED
- Portable to most operating systems.
-
- AVAILABILITY
- Commercially available from:
- Netlabs Inc
- 11693 Chenault Street Ste 348
- Los Angeles CA 90049
- (213) 476-4070
- lam@netlabs.com (Anne Lam)
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 62]
-
- Internet Tool Catalog NETMON (I)
-
-
- NAME
- netmon
-
- KEYWORDS
- status; DNS, IP; ping; DOS; free.
-
- ABSTRACT
- Netmon is a DOS-based program that pings hosts on a
- monitored list at user-specified intervals. In addi-
- tion, a user may optionally ping hosts not on the list.
-
- Netmon also performs domain lookups. Furthermore, a
- user may build and send a domain query to any desired
- DNS server.
-
- MECHANISM
- The tool works by using the echo service feature of
- ICMP. It reports if it receives an incorrect response
- or no response.
-
- CAVEATS
- Depending on the frequency of pinging and the number of
- hosts pinged, netmon could create a high volume of
- traffic.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- A PC, and a Western Digital WD8003 interface card (or
- any other card for which there is a packet driver for
- FTP Software Inc.'s PC/TCP kernel). Both monochrome
- and color displays are supported, though color is
- recommended.
-
- SOFTWARE REQUIRED
- DOS operating system, and the PC/TCP Kernel by FTP
- Software, Inc.
-
- AVAILABILITY
- The BYU modified version is available for anonymous FTP
- from Dcsprod.byu.edu, in directory "programs." It can
- be freely distributed for non-commercial use.
-
-
-
-
-
- IETF NOCTools Working Group [Page 63]
-
- Internet Tool Catalog NETMON (II)
-
-
- NAME
- NETMON and iptrace
-
- KEYWORDS
- traffic; IP; eavesdrop; UNIX; free.
-
- ABSTRACT
- NETMON is a facility to enable communication of net-
- working events from the BSD UNIX operating system to a
- user-level network monitoring or management program.
- Iptrace is a program interfacing to NETMON which logs
- TCP-IP traffic for performance measurement and gateway
- monitoring. It is easy to build other NETMON-based
- tools using iptrace as a model.
-
- NETMON resides in the 4.3BSD UNIX kernel. It is
- independent of hardware-specific code in UNIX. It is
- transparent to protocol and network type, having no
- internal assumptions about the network protocols being
- recorded. It is installed in BSD-like kernels by
- adding a standard function call (probe) to a few points
- in the input and output routines of the protocols to be
- logged.
-
- NETMON is analogous to Sun Microsystems' NIT, but the
- interface tap function is extended by recording more
- context information. Aside from the timestamp, the
- choice of information recorded is up to the installer
- of the probes. The NETMON probes added to the BSD IP
- code supplied with the distribution include as context:
- input and output queue lengths, identification of the
- network interface, and event codes labeling packet dis-
- cards. (The NETMON distribution is geared towards
- measuring the performance of BSD networking protocols
- in an IP gateway).
-
- NETMON is designed so that it can reside within the
- monitored system with minimal interference to the net-
- work processing. The estimated and measured overhead
- is around five percent of packet processing.
-
- The user-level tool "iptrace" is provided with NETMON.
- This program logs IP traffic, either at IP-level only,
- or as it passes through the network interface drivers
- as well. As a separate function, iptrace produces a
- host traffic matrix output. Its third type of output
- is abbreviated sampling, in which only a pre-set number
- of packets from each new host pair is logged. The
-
-
-
- IETF NOCTools Working Group [Page 64]
-
- Internet Tool Catalog NETMON (II)
-
-
- three output types are configured dynamically, in any
- combination.
-
- OSITRACE, another logging tool with a NETMON interface,
- is available separately (and documented in a separate
- entry in this catalog).
-
- MECHANISM
- Access to the information logged by NETMON is through a
- UNIX special file, /dev/netmon. User reads are blocked
- until the buffer reaches a configurable level of full-
- ness.
-
- Several other parameters of NETMON can be tuned at com-
- pile time. A diagnostic program, netmonstat, is
- included in the distribution.
-
- CAVEATS
- None.
-
- BUGS
- Bug reports and questions should be addressed to:
- ie-tools@gateway.mitre.org
- Requests to join this mailing list:
- ie-tools-request@gateway.mitre.org
- Questions and suggestions can also be directed to:
- Allison Mankin (703)883-7907
- mankin@gateway.mitre.org
-
- LIMITATIONS
- A NETMON interface for tcpdump and other UNIX protocol
- analyzers is not included, but it is simple to write.
- NETMON probes for a promiscuous ethernet interface are
- similarly not included.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX-like network protocols or the ability to
- install the BSD publicly available network protocols in
- the system to be monitored.
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 65]
-
- Internet Tool Catalog NETMON (II)
-
-
-
- AVAILABILITY
- The NETMON distribution is available by anonymous FTP
- in pub/netmon.tar or pub/netmon.tar.Z from aelred-
- 3.ie.org. A short user's and installation guide,
- NETMON.doc, is available in the same location. The
- NETMON distribution is provided "as is" and requires
- retention of a copyright text in code derived from it.
- It is copyrighted by the MITRE-Washington Networking
- Center.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 66]
-
- Internet Tool Catalog NETMON (III)
-
-
- NAME
- NETMON -- an SNMP-based network management tool from
- SNMP Research.
-
- KEYWORDS
- alarm, control, manager, map, routing; DECnet, ether-
- net, IP, OSI, ring, star; NMS, SNMP; DOS; sourcelib.
-
- ABSTRACT
- The NETMON application implements a network management
- station based on a low-cost DOS-based platform. It can
- be successfully used with many types of networks,
- including both wide area networks and those based on
- various LAN media. NETMON has been used with multipro-
- tocol devices including those which support TCP/IP,
- DECnet, and OSI protocols. The fault management tool
- displays the map of the network configuration with
- current node and link state indicated in one of several
- colors. Alarms may be enabled to alert the operator of
- events occurring in the network. Events are logged to
- disk. The NETMON application comes complete with
- source code including a powerful set of portable
- libraries for generating and parsing SNMP messages.
- Output data from NETMON may be transferred via flat
- files for additional report generation by a variety of
- statistical packages.
-
- MECHANISM
- The NETMON application is based on the Simple Network
- Management Protocol (SNMP). Polling is performed via
- the powerful SNMP get-next operator and the SNMP get
- operator. Trap directed polling is used to regulate
- the focus and intensity of the polling.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- The monitored and managed nodes must implement the SNMP
- over UDP per RFC 1098 or must be reachable via a proxy
- agent.
-
- HARDWARE REQUIRED
- The minimum system is a IBM Personal Computer (4.77
- MHz) with DOS 3.0 or later, an Enhanced Graphics
-
-
-
- IETF NOCTools Working Group [Page 67]
-
- Internet Tool Catalog NETMON (III)
-
-
- Adapter, Enhanced Graphics Monitor, a single 360 Kbyte
- floppy drive, and an ethernet adapter. However, most
- users will find a hard disk to be helpful for storing
- network history and will be less impatient with a fas-
- ter CPU.
-
- SOFTWARE REQUIRED
- DOS 3.0 or later and TCP/IP software from one of
- several sources.
-
- AVAILABILITY
- This is a commercial product available under license
- from:
-
- SNMP Research
- P.O. Box 8593
- Knoxville, TN 37996-4800
- (615) 573-1434 (Voice)
- (615) 573-9197 (FAX)
- Attn: Dr. Jeff Case
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 68]
-
- Internet Tool Catalog NETSTAT
-
-
- NAME
- netstat
-
- KEYWORDS
- routing; IP; UNIX, VMS; free.
-
- ABSTRACT
- Netstat is a program that accesses network related data
- structures within the kernel, then provides an ASCII
- format at the terminal. Netstat can provide reports on
- the routing table, TCP connections, TCP and UDP
- "listens", and protocol memory management.
-
- MECHANISM
- Netstat accesses operating system memory to read the
- kernel routing tables.
-
- CAVEATS
- Kernel data structures can change while netstat is run-
- ning.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS, or VMS.
-
- AVAILABILITY
- Available via anonymous FTP from uunet.uu.net, in
- directory bsd-sources/src/ucb. Available with 4.xBSD
- UNIX and related operating systems. For VMS, available
- as part of TGV MultiNet IP software package, as well as
- Wollongong's WIN/TCP.
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 69]
-
- Internet Tool Catalog NETWATCH
-
-
- NAME
- netwatch
-
- KEYWORDS
- traffic; ethernet, IP, ring; eavesdrop; DOS; free.
-
- ABSTRACT
- PC/netwatch listens to an attached local broadcast net-
- work and displays one line of information for every
- packet that goes by. This information consists of the
- "to" and "from" local network addresses, the packet
- length, the value of the protocol type field, and 8
- selected contiguous bytes of the packet contents.
- While netwatch is running it will respond to commands
- to display collected information, change its operating
- mode, or to filter for specific types of packets.
-
- MECHANISM
- Puts controller in promiscuous mode.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- The monitor can handle a burst rate of about 200 pack-
- ets per second. Packets arriving faster than that are
- missed (but counted in the statistics of the network
- driver). The display rate is about 25 packets per
- second and there is a buffer that can hold 512
- undisplayed packets. The monitor discards overflow
- packets.
-
- HARDWARE REQUIRED
- IBM PC compatible with CGA and network interface (3com
- 3C501, Interlan NI5010, or proNet p1300).
-
- SOFTWARE REQUIRED
- DOS 2.0 or higher, MicroSoft C (to generate custom exe-
- cutables)
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 70]
-
- Internet Tool Catalog NETWATCH
-
-
-
- AVAILABILITY
- Available as a utility program in the pcip distribution
- from host husc6.harvard.edu, in directory pub/pcip.
- Available in a standalone package via anonymous FTP
- from windom.ucar.edu, in file pc/network/netwatch.arc;
- a binary "dearc" program is also available from
- windom.ucar.edu.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 71]
-
- Internet Tool Catalog NETWORK INTEGRATOR I
-
-
- NAME
- Network Integrator I
-
- KEYWORDS
- map, traffic; ethernet; UNIX.
-
- ABSTRACT
- This tool monitors traffic on network segments. All
- information is dumped to either a log file or, for
- real-time viewing, to a command tool window. Data is
- time-stamped according to date and time. Logging can
- continue for up to 24 hours.
-
- The tool is flexible in data collection and presenta-
- tion. Traffic filters can be specified according to
- header values of numerous protocols, including those
- used by Apple, DEC, Sun, HP, and Apollo. Bandwidth
- utilization can be monitored, as well as actual load
- and peak throughput. Additionally, the Network
- Integrator can analyze a network's topology, and record
- the location of all operational nodes on a network.
-
- Data can be displayed in six separate formats of bar
- graphs. In addition, there are several routines for
- producing statistical summaries of the data collected.
-
- MECHANISM
- The tools work through RPC and XDR calls.
-
- CAVEATS
- Although the tool adds only little traffic to a net-
- work, generation of statistics from captured files
- requires a significant portion of a workstation's CPU.
-
- BUGS
- None known.
-
- LIMITATIONS
- Must be root to run monitor. There does not seem to be
- a limit to the number of nodes, since it monitors by
- segments. The only major limitation is the amount of
- disk space that a user can commit to the log files.
- The size of the log files, however, can be controlled
- through the tool's parameters.
-
- HARDWARE REQUIRED
- Sun3 or Sun4.
-
-
-
-
- IETF NOCTools Working Group [Page 72]
-
- Internet Tool Catalog NETWORK INTEGRATOR I
-
-
- SOFTWARE REQUIRED
- 4.0BSD UNIX or greater, or related OS.
-
- AVAILABILITY
- Copyrighted, commercially available from
- Network Integrators,
- (408) 927-0412.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 73]
-
- Internet Tool Catalog NET_MONITOR
-
-
- NAME
- net_monitor
-
- KEYWORDS
- routing, status; DECnet, IP; curses, ping; UNIX, VMS;
- free, sourcelib.
-
- ABSTRACT
- Net_monitor uses ICMP echo (and DECnet reachability
- information on VAX/VMS) to monitor a network. The mon-
- itoring is very simplistic, but has proved useful. It
- periodically tests whether hosts are reachable and
- reports the results in a full-screen display. It
- groups hosts together in common sets. If all hosts in
- a set become unreachable, it makes a lot of racket with
- bells, since it assumes that this means that some com-
- mon piece of hardware that supports that set has
- failed. The periodicity of the tests, hosts to test,
- and groupings of hosts are controlled with a single
- configuration file.
-
- The idea for this program came from the PC/IP monitor
- facility, but is an entirely different program with
- different functionality.
-
- MECHANISM
- Reachability is tested using ICMP echo facilities for
- TCP/IP hosts (and DECnet reachability information on
- VAX/VMS). A DECnet node is considered reachable if it
- appears in the list of hosts in a "show network" com-
- mand issued on a routing node.
-
- CAVEATS
- This facility has been found to be most useful when run
- in a window on a workstation rather than on a terminal
- connected to a host. It could be useful if ported to a
- PC (looks easy using FTP Software's programming
- libraries), but this has not been done. Curses is very
- slow and cpu intensive on VMS, but the tool has been
- run in a window on a VAXstation 2000. Just don't try
- to run it on a terminal connected to a 11/750.
-
- BUGS
- None known.
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 74]
-
- Internet Tool Catalog NET_MONITOR
-
-
-
- LIMITATIONS
- This tool is not meant to be a replacement for a more
- comprehensive network management facility such as is
- provided with SNMP.
-
- HARDWARE REQUIRED
- A host with a network connection.
-
- SOFTWARE REQUIRED
- Curses, 4.xBSD UNIX socket programming libraries (lim-
- ited set) and some flavor of TCP/IP that supports ICMP
- echo request (ping). It has been run on VAX/VMS run-
- ning WIN/TCP and several flavors of 4BSD UNIX (includ-
- ing SunOS 3.2, 4.0, and 4.3BSD). It could be ported to
- any platform that provides a BSD-style programming li-
- brary with an ICMP echo request facility and curses.
-
- AVAILABILITY
- Requests should be sent to the author:
-
- Dale Smith
- Asst Dir of Network Services
- University of Oregon
- Computing Center
- Eugene, OR 97403-1211
-
- Internet: dsmith@oregon.uoregon.edu.
- BITNET: dsmith@oregon.bitnet
- UUCP: ...hp-pcd!uoregon!dsmith
- Voice: (503)686-4394
-
- With the source code, a makefile is provided for most
- any UNIX box and a VMS makefile compatible with the
- make distributed with PMDF. A VMS DCL command file is
- also provided, for use by those VMS sites without
- "make."
-
- The author will attempt to fix bugs, but no support is
- promised. The tool is copyrighted, but free (for now).
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 75]
-
- Internet Tool Catalog NFSWATCH
-
-
- NAME
- nfswatch
-
- KEYWORDS
- traffic; ethernet, IP, NFS; curses, eavesdrop; UNIX;
- free.
-
- ABSTRACT
- Nfswatch monitors all incoming ethernet traffic to an
- NFS file server and divides it into several categories.
- The number and percentage of packets received in each
- category is displayed on the screen in a continuously
- updated display.
-
- All exported file systems are monitored by default.
- Other files may optionally be monitored. Options also
- allow monitoring of traffic destined for a remote host
- instead of the local host, or monitoring traffic sent
- by a single host. Items such as the sample interval
- length can be adjusted either on the command line or
- interactively. Facilities for taking screen
- "snapshots," saving all data to a log file, and summar-
- izing the log file are included. Nfslogsum, a program
- that summarizes the log file, is included in the dis-
- tribution.
-
- MECHANISM
- Nfswatch uses the Network Interface Tap in promiscuous
- mode to monitor the ethernet. It filters out NFS pack-
- ets destined for the local (or remote) host, and then
- decodes the file handles in order to determine which
- file or file system a request pertains to.
-
- CAVEATS
- Because the NFS file handle is a non-standard (server
- private) piece of data, the file system monitoring part
- of the program will break whenever the format of a file
- handle is not what it expects to see. This is easily
- fixed in the code, however. The code presently under-
- stands SunOS 4.0 file handles.
-
- BUGS
- None known.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 76]
-
- Internet Tool Catalog NFSWATCH
-
-
-
- LIMITATIONS
- Up to 256 exported file systems and 256 individual
- files can be monitored, but only (2 * (DisplayLines -
- 16)) will be displayed on the screen (all data will be
- written to the log file).
-
- Only NFS requests made by client machines are counted;
- the NFS traffic generated by the server in response to
- these requests is not counted.
-
- HARDWARE REQUIRED
- Has been tested on Sun-3 and Sun-4 systems. No
- hardware dependencies, but see below.
-
- SOFTWARE REQUIRED
- SunOS 4.0 or higher. The STREAMS NIT device is used.
- Fairly easy code modifications should be able to make
- it run under older SunOS releases, or other versions of
- BSD UNIX with a NIT-like device.
-
- AVAILABILITY
- Copyrighted, but freely distributable. Available via
- anonymous FTP from hosts icarus.riacs.edu and
- spam.itstd.sri.com in pub/nfswatch.tar.Z. There should
- also be a copy on the 1989 Sun User's Group tape.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 77]
-
- Internet Tool Catalog NHFSSTONE
-
-
- NAME
- nhfsstone
-
- KEYWORDS
- benchmark, generator; NFS; spoof; UNIX; free.
-
- ABSTRACT
- Nhfsstone (pronounced n-f-s-stone, the "h" is silent)
- is an NFS benchmarking program. It is used on an NFS
- client to generate an artificial load with a particular
- mix of NFS operations. It reports the average response
- time of the server in milliseconds per call and the
- load in calls per second. The nhfsstone distribution
- includes a script, "nhfsnums" that converts test
- results into plot(5) format so that they can be graphed
- using graph(1) and other tools.
-
- MECHANISM
- Nhfsstone is an NFS traffic generator. It adjusts its
- calling patterns based on the client's kernel NFS
- statistics and the elapsed time. Load can be generated
- over a given time or number of NFS calls.
-
- CAVEATS
- Nhfsstone will compete for system resources with other
- applications.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- 4.xBSD-based UNIX
-
- AVAILABILITY
- Available via anonymous FTP from bugs.cs.wisc.edu.
- Alternatively, Legato Systems will provide the program
- free of charge, if certain conditions are met. Send
- name and both email and U.S. mail addresses to:
- Legato Systems, Inc.
- Nhfsstone
- 260 Sheridan Avenue
- Palo Alto, California 94306
-
-
-
- IETF NOCTools Working Group [Page 78]
-
- Internet Tool Catalog NHFSSTONE
-
-
-
- A mailing list is maintained for regular information
- and bug fixes: nhfsstone@legato.com or
- uunet!legato.com!nhfsstone. To join the list:
- nhfsstone-request@legato.com or
- uunet!legato.com!nhfsstone-request.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 79]
-
- Internet Tool Catalog NMC
-
-
- NAME
- NMC -- the Hughes LAN Systems 9100 Network Management
- Center
-
- KEYWORDS
- control, manager, routing, status, traffic; bridge,
- DECnet, ethernet, IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- The 9100 Network Management Center provides the capa-
- bility to manage and control standards-based networking
- products from Hughes LAN Systems' and other vendors.
- This management extends to all network products that
- are equipped with the industry standard SNMP (Simple
- Network Management Protocol). A comprehensive rela-
- tional database manages the data and ensures easy
- access and control of resources throughout the network.
-
- 9100 NMC software provides the following functions:
-
- Database Management
- Stores and retrieves the information required to
- administer and configure the network. It can be
- used to:
- Store and recall configuration data for all
- devices.
- Provide availability history for devices.
- Provides full-function SQL interface.
- Assign new internet addresses.
- Provide administrative information such as
- physical location of devices, person respon-
- sible, maintenance history, asset data,
- hardware/software versions, etc.
-
- Configuration Management
- A comprehensive configuration model that enables
- you to:
- Retrieve configuration information from SNMP
- devices.
- Configure HLS devices using SNMP.
- Configures attributes relating to TCP/IP,
- DECnet and other protocols in HLS devices
- using SNMP.
- Poll devices to compare their current attri-
- bute values with those in the database and
- produce reports of the discrepancies.
- Collect data about the state of the network.
-
-
-
-
- IETF NOCTools Working Group [Page 80]
-
- Internet Tool Catalog NMC
-
-
-
- Performance Management
- Displays local network traffic graphically, by
- packet size, protocol, network utilization,
- sources and destinations of packets, etc.
-
- Fault Management
- Provides availability monitoring and indicates
- potential problems.
- Scheduled availability monitoring of devices.
- SNMP traps (alarms) are recorded in an alarm
- log.
- New alarms are indicated by a flashing icon
- and optional audio alert.
- Possible causes and suggested actions for the
- alarms are listed.
- Cumulative reports can be produced.
-
- Utilities Function
- Allows you to view and/or stop existing NMC
- processes, and to define schedules for invoking
- NMC applications and database maintenance utili-
- ties.
-
- MECHANISM
- SNMP.
-
- CAVEATS
- None reported.
-
- BUGS
- None known.
-
- LIMITATIONS
- Maximum number of nodes that can be monitored is
- 18,000. This can include Hosts, Terminal Servers, PCs,
- and Bridges.
-
- HARDWARE REQUIRED
- The host for the NMC software is a Sun 3 desktop works-
- tation. Recommended minimum hardware is the Sun 3/80
- Color with a 1/4" SCSI tape drive.
-
- SOFTWARE REQUIRED
- The NMC, which is provided on 1/4" tape format, runs on
- the Sun 4.0 Operating System.
-
-
-
-
-
- IETF NOCTools Working Group [Page 81]
-
- Internet Tool Catalog NMC
-
-
-
- AVAILABILITY
- A commercial product of:
- Hughes LAN Systems Inc.
- 1225 Charleston Road
- Mountain View, CA 94043
- Phone: (415) 966-7300
- Fax: (415) 960-3738
- RCA Telex: 276572
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 82]
-
- Internet Tool Catalog NNSTAT
-
-
- NAME
- NNStat
-
- KEYWORDS
- manager, status, traffic; ethernet, IP; eavesdrop, NMS;
- UNIX; free.
-
- ABSTRACT
- NNStat is a collection of programs that provides an
- internet statistic collecting capability. The NNStat
- strategy for statistic collection is to collect traffic
- statistics via a promiscuous ethernet tap on the local
- networks, versus instrumenting the gateways. If all
- traffic entering or leaving a network or set of net-
- works traverses a local ethernet, then by stationing a
- statistic gathering agent on each local network a pro-
- file of network traffic can be gathered. Statistical
- data is retrieved from the local agents by a global
- manager.
-
- A program called "statspy" performs the data gathering
- function. Essentially, statspy reads all packets on an
- ethernet interface and records all information of
- interest. Information of interest is gathered by exa-
- mining each packet and determining if the source or
- destination IP address is one that is being monitored,
- typically a gateway address. If so then the contents
- of the packet are examined to see if they match further
- criteria.
-
- A program called "collect" performs global data collec-
- tion. It periodically polls various statspy processes
- in the domain of interest to retrieve locally logged
- statistical data.
-
- The NNSTAT distribution comes with several sample awk
- programs which process the logged output of the collect
- program.
-
- MECHANISM
- Local agents (statspy processes) collect raw traffic
- data via a promiscuous ethernet tap. Statistical, fil-
- tered or otherwise reduced data is retrieved from the
- local agents by a global manager (the "collect" pro-
- cess).
-
- CAVEATS
- None.
-
-
-
- IETF NOCTools Working Group [Page 83]
-
- Internet Tool Catalog NNSTAT
-
-
-
- BUGS
- Bug fixes, extensions, and other pointers are discussed
- in the electronic mail forum, bytecounters. To join,
- send a request to bytecounters-request@venera.isi.edu.
- Forum exchanges are archived in the file
- bytecounters/bytecounters.mail, available via anonymous
- FTP from venera.isi.edu.
-
- LIMITATIONS
- NNStat presumes a topology of one or more long haul
- networks gatewayed to local ethernets.
-
- A kernel mod required to run with SunOS4. These mods
- are described in the bytecounters archive.
-
- HARDWARE REQUIRED
- Ethernet interface. Sun 3, Sun 4 (SPARC), or PC RT
- workstation.
-
- SOFTWARE REQUIRED
- Distribution is for BSD UNIX, could easily be adapted
- to any UNIX with promiscuous ethernet support.
-
- AVAILABILITY
- Distribution is available via anonymous FTP from
- venera.isi.edu, in file pub/NNStat.tar.Z. Documenta-
- tion is in pub/NNStat.userdoc.ms.Z.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 84]
-
- Internet Tool Catalog NPRV
-
-
- NAME
- NPRV -- IP Node/Protocol Reachability Verifier
-
- KEYWORDS
- map, routing, status; IP; ping; VMS; free.
-
- ABSTRACT
- NPRV is a full-screen, keypad-oriented utility that
- runs under VAX/VMS. It allows the user to quickly scan
- through a user-defined list of IP addresses (or domain
- names) and verify a node's reachability. The node's
- reachability is determined by performing an ICMP echo,
- UDP echo and a TCP echo at alternating three second
- intervals. The total number of packets sent and
- received are displayed, as well as the minimum, average
- and maximum round-trip times (in milliseconds) for each
- type of echo. Additionally, a "trace route" function
- is performed to determine the path from the local sys-
- tem to the remote host. Once all of the trace route
- information has filled the screen, a "snapshot" of the
- screen can be written to a text file. Upon exiting the
- utility, these text files can be used to generate a
- logical network map showing host and gateway intercon-
- nectivity.
-
- MECHANISM
- The ICMP echo is performed by sending ICMP ECHO REQUEST
- packets. The UDP and TCP echoes are performed by con-
- necting to the UDP/TCP echo ports (port number 7). The
- trace route information is compiled by sending alter-
- nating ICMP ECHO REQUEST packets and UDP packets with
- very large destination UDP port numbers (in two
- passes). Each packet is initially sent with a TTL
- (time to live) of 1. This should cause an ICMP TIME
- EXCEEDED error to be generated by the first routing
- gateway. Then each packet is sent with a TTL of 2.
- This should cause an ICMP TIME EXCEEDED error to be
- generated by the second routing gateway. Then each
- packet is sent with a TTL of 3, and so on. This pro-
- cess continues until an ICMP ECHO REPLY or UDP PORT
- UNREACHABLE is received. This indicates that the
- remote host has been reached and that the trace route
- information is complete.
-
- CAVEATS
- This utility sends one echo packet per second (ICMP,
- UDP or TCP), as well as sending out one trace route
- packet per second. If a transmitted trace route packet
-
-
-
- IETF NOCTools Working Group [Page 85]
-
- Internet Tool Catalog NPRV
-
-
- is returned in less than one second, another trace
- route packet is sent in 100 milliseconds. This could
- cause a significant amount of contention on the local
- network.
-
- BUGS
- None known. Please report any discovered bugs to the
- author at:
- Allen Sturtevant
- National Magnetic Fusion Energy Computer Center
- Lawrence Livermore National Laboratory
- P.O. Box 808; L-561
- Livermore, CA 94550
- Phone : (415) 422-8266
- E-Mail: sturtevant@ccc.nmfecc.gov
-
- LIMITATIONS
- The user is required to have SYSPRV privilege to per-
- form the ICMP Echo and trace route functions. The
- utility will still run with this privilege disabled,
- but only the UDP Echo and TCP Echo information will be
- displayed. This utility is written in C, but unfor-
- tunately it cannot be easily ported over to UNIX since
- many VMS system calls are used and all screen I/O is
- done using the VMS Screen Management Routines.
-
- HARDWARE REQUIRED
- Any network interface supported by TGV Incorporated's
- MultiNet software.
-
- SOFTWARE REQUIRED
- VAX/VMS V5.1+ and TGV Incorporated's MultiNet version
- 2.0.
-
- AVAILABILITY
- For executables only, FTP to the ANONYMOUS account
- (password GUEST) on CCC.NMFECC.GOV (128.55.128.30) and
- GET the following files:
-
- [ANONYMOUS.PROGRAMS.NPRV]NPRV.DOC (ASCII text)
- [ANONYMOUS.PROGRAMS.NPRV]NPRV.EXE (binary)
- [ANONYMOUS.PROGRAMS.NPRV]SAMPLE.IPA (ASCII text)
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 86]
-
- Internet Tool Catalog NSLOOKUP
-
-
- NAME
- nslookup
-
- KEYWORDS
- status; DNS; spoof; UNIX, VMS; free.
-
- ABSTRACT
- Nslookup is a program used for interactive query of
- ARPA Internet domain servers. This program is useful
- for diagnosing routing or mail delivery problems, where
- often a local domain server is responding with an
- incorrect internet address. It is essentially a data-
- base front end which converts user queries into domain
- name queries. By default nslookup queries the local
- domain name server but you can specify additional
- servers. Additional information beyond the mapping of
- domain names to internet addresses is possible.
-
- MECHANISM
- Formats and sends domain name queries.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None known.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS, or VMS.
-
- AVAILABILITY
- Nslookup is part of the "named" distribution, available
- via anonymous FTP from uunet.uu.net, in directories
- bsd-sources/src/etc and bsd-sources/src/network, and
- part of the "bind" distribution, available via
- anonymous FTP from ucbarpa.berkeley.edu, in directory
- 4.3. Also available with 4.xBSD UNIX and related
- operating systems. For VMS, available as part of TGV
- MultiNet IP software package, as well as Wollongong's
- WIN/TCP.
-
-
-
-
-
- IETF NOCTools Working Group [Page 87]
-
- Internet Tool Catalog OSILOG
-
-
- NAME
- osilog -- OSI event Logger
-
- KEYWORDS
- alarm, manager; OSI; UNIX; free.
-
- ABSTRACT
- The osilog program receives management event reports
- for the operation of the ISODE Transport layer (ISO
- Transport Protocol class 0) on one or more managed sys-
- tems, formats them suitably to facilitate post-
- processing and records them for future analysis.
-
- MECHANISM
- It communicates with the System Management Agents
- (SMAs) on the selected systems via CMIP.
-
- CAVEATS
- The System Management Agent (SMA) must be running on
- the hosts selected to provide management reports.
-
- BUGS
- None known.
-
- LIMITATIONS
- ISODE Transport Layer only supported by the SMA at
- present.
-
- HARDWARE REQUIRED
- Developed and tested on Sun3.
-
- SOFTWARE REQUIRED
- The ISODE protocol suite, BSD UNIX.
-
- AVAILABILITY
- The osilog and related tools, known as OSIMIS (OSI
- Management Information Service), are publicly available
- from University College London, England via FTP and
- FTAM. To obtain information regarding a copy send
- email to gknight@ac.ucl.cs.uk or call +44 1 380 7366.
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 88]
-
- Internet Tool Catalog OSIMIC
-
-
- NAME
- osimic -- OSI Microscope
-
- KEYWORDS
- manager, status; OSI; UNIX; free.
-
- ABSTRACT
- The osimic program is a human user interface to the
- management information base on the ISODE Transport
- layer (ISO Transport Protocol class 0). It allows
- browsing through the management information tree and
- enables the manipulation of attribute values. It is
- implemented using the SunView package of the SunTools
- window system.
-
- MECHANISM
- It communicates with the System Management Agent (SMA)
- on the selected system via CMIP.
-
- CAVEATS
- The System Management Agent (SMA) must be running on
- the host where the mib is being examined.
-
- BUGS
- None known.
-
- LIMITATIONS
- ISODE Transport Layer only supported by the SMA at
- present.
-
- HARDWARE REQUIRED
- Developed and tested on Sun3.
-
- SOFTWARE REQUIRED
- The ISODE protocol suite, BSD UNIX, SunView/SunTools.
-
- AVAILABILITY
- The osimic and related tools, known as OSIMIS (OSI
- Management Information Service), are publicly available
- from University College London, England via FTP and
- FTAM. To obtain information regarding a copy send
- email to gknight@ac.ucl.cs.uk or call +44 1 380 7366.
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 89]
-
- Internet Tool Catalog OSIMON
-
-
- NAME
- osimon -- OSI Monitor
-
- KEYWORDS
- manager, status, traffic; OSI; curses; UNIX; free.
-
- ABSTRACT
- The osimon program monitors activity of the ISODE Tran-
- sport layer (ISO Transport Protocol class 0), display-
- ing entries for the active transport entities and con-
- nections. The display is dynamically updated in the
- case of significant events such as connection opening
- and closing and packet traffic, as information is
- received in the form of event reports from a SMA. It
- uses the UNIX curses package for screen management.
-
- MECHANISM
- It communicates with the System Management Agent (SMA)
- on the selected system via CMIP.
-
- CAVEATS
- The System Management Agent (SMA) must be running on
- the host being monitored.
-
- BUGS
- For the terminal type Sun, there are some transient
- problems with the display.
-
- LIMITATIONS
- ISODE Transport Layer only supported at present.
-
- HARDWARE REQUIRED
- Developed and tested on Sun3 for various terminal
- types.
-
- SOFTWARE REQUIRED
- The ISODE protocol suite, BSD UNIX.
-
- AVAILABILITY
- The osimon and related tools, known as OSIMIS (OSI
- Management Information Service), are publicly available
- from University College London, England via FTP and
- FTAM. To obtain information regarding a copy send
- email to gknight@ac.ucl.cs.uk or call +44 1 380 7366.
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 90]
-
- Internet Tool Catalog OSITRACE
-
-
- NAME
- OSITRACE
-
- KEYWORDS
- traffic; OSI; eavesdrop; UNIX; free.
-
- ABSTRACT
- OSITRACE is a network performance tool that displays
- information about ISO TP4 connections. One line of
- output is displayed for each packet indicating the
- time, source, destination, length, packet type,
- sequence number, credit, and any optional parameters
- contained in the packet. Numerous options are avail-
- able to control the output of OSITRACE.
-
- To obtain packets to analyze, OSITRACE uses Sun
- Microsystems' Network Interface Tap (NIT) in SunOS 3.4,
- 3.5, and 4.0.X. OSITRACE may also obtain data from the
- NETMON utility which is described as another tool
- entry.
-
- In Sun systems, OSITRACE may be easily installed: OSI
- kernel support is not needed, nor is any other form of
- OSI software support.
-
- MECHANISM
- This tool has been designed in such a way that code to
- process different protocol suites may be easily added.
- As such, OSITRACE also has the ability to trace the DOD
- TCP protocols.
-
- CAVEATS
- None.
-
- BUGS
- Bug reports and questions should be addressed to: ie-
- tools@gateway.mitre.org
-
- Requests to join this mailing list: ie-tools-
- request@gateway.mitre.org
-
- Questions and suggestions can also be directed to: Greg
- Hollingsworth, gregh@gateway.mitre.org
-
- LIMITATIONS
- None reported.
-
-
-
-
-
- IETF NOCTools Working Group [Page 91]
-
- Internet Tool Catalog OSITRACE
-
-
-
- HARDWARE REQUIRED
- No restriction.
-
- SOFTWARE REQUIRED
- SunOS 3.4, 3.5, or 4.0.X, or BSD UNIX-like network pro-
- tocols with NETMON installed.
-
- AVAILABILITY
- OSITRACE is copyrighted by the MITRE-Washington Net-
- working Center, but freely distributed "as is." It re-
- quires retention of a copyright text in code derived
- from it. The distribution is available by anonymous
- FTP in pub/pdutrace.tar or pub/pdutrace.tar.Z from
- aelred-3.ie.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 92]
-
- Internet Tool Catalog OVERVIEW
-
-
- NAME
- OverVIEW
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; DOS.
-
- ABSTRACT
- Network and internet monitor; Performance monitor;
- Fully Graphic user interface; Event logging; TFTP boot
- server
-
- MECHANISM
- OverVIEW uses SNMP to query routers, gateways and
- hosts. Also supports SGMP, PING and is committed to
- CMIP/CMOT. The SNMP queries allow dynamic determina-
- tion of configuration and state. Sets of related
- queries allows monitoring of congestion and faults.
- The hardware and software are sold as an integrated
- package.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- 256 nodes, 256 nets
-
- HARDWARE REQUIRED
- 80286, 640K, EGA, mouse.
-
- SOFTWARE REQUIRED
- MS-DOS, OverVIEW, Network kernel, Mouse driver, SNMP
- agents for monitored devices.
-
- AVAILABILITY
- Fully supported product of Proteon, Inc. For more
- information, contact:
- Proteon, Inc. Phone: (508) 898-2800
- 2 Technology Drive Fax: (508) 366-8901
- Westborough, MA 01581 Telex: 928124
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 93]
-
- Internet Tool Catalog PING
-
-
- NAME
- ping
-
- KEYWORDS
- generator, status; IP; ping; DOS, UNIX, VMS; free.
-
- ABSTRACT
- Ping is perhaps the most basic tool for internet
- management. It verifies that a remote IP implementa-
- tion and the intervening networks and interfaces are
- functional. It can be used to measure round trip
- delay. Numerous versions of the ping program exist.
-
- MECHANISM
- Ping is based on the ICMP ECHO_REQUEST message.
-
- CAVEATS
- If run repeatedly, ping could generate high system
- loads.
-
- BUGS
- None known.
-
- LIMITATIONS
- PC/TCP's ping is the only implementation known support
- both loose and strict source routing. Though some ping
- implementations support the ICMP "record route"
- feature, the usefulness of this option for debugging
- routes is limited by the fact that many gateways do not
- correctly implement it.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- None.
-
- AVAILABILITY
- Ping is widely included in TCP/IP distributions. Pub-
- lic domain versions of ping are available via anonymous
- FTP from uunet.uu.net, in directory bsd-
- sources/src/etc, and from venera.isi.edu, in directory
- pub.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 94]
-
- Internet Tool Catalog PROXYD
-
-
- NAME
- proxyd -- SNMP proxy agent daemons from SNMP Research.
-
- KEYWORDS
- control, status; bridge, ethernet, IP, ring, star; NMS,
- SNMP; UNIX; library, sourcelib.
-
- ABSTRACT
- SNMP proxy agents may be used to permit the monitoring
- and controlling of network elements which are otherwise
- not addressable using the SNMP management protocol
- (e.g., a network bridge that implements a proprietary
- management protocol). Similarly, SNMP proxy agents may
- be used to protect SNMP agents from redundant network
- management agents through the use of caches. Finally,
- SNMP proxy agents may be used to implement elaborate
- MIB access policies. The proxy agent daemon listens
- for SNMP queries and commands from logically remote
- network management stations, translates and retransmits
- those as appropriate network management queries or
- cache lookups, listens for and parses the responses,
- translates the responses into SNMP responses, and
- returns those responses as SNMP messages to the network
- management station that originated the transaction.
- The proxy agent daemon also emits SNMP traps to identi-
- fied trap receivers. The proxy agent daemon is archi-
- tected to make the addition of additional vendor-
- specific variables a straight-forward task. The proxy
- application comes complete with source code including a
- powerful set of portable libraries for generating and
- parsing SNMP messages and a set of command line utili-
- ties.
-
- MECHANISM
- Network management variables are made available for
- inspection and/or alteration by means of the Simple
- Network Management Protocol (SNMP).
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- This application is a template for proxy application
- writers.
-
-
-
-
- IETF NOCTools Working Group [Page 95]
-
- Internet Tool Catalog PROXYD
-
-
- Only a few of the many LanBridge 100 variables are sup-
- ported.
-
- HARDWARE REQUIRED
- System from Sun Microsystems, Incorporated.
-
- SOFTWARE REQUIRED
- Sun OS 3.5 or 4.x
-
- AVAILABILITY
- This is a commercial product available under license
- from:
-
- SNMP Research
- P.O. Box 8593
- Knoxville, TN 37996-4800
- (615) 573-1434 (Voice)
- (615) 573-9197 (FAX)
- Attn: Dr. Jeff Case
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 96]
-
- Internet Tool Catalog QUERY
-
-
- NAME
- query, ripquery
-
- KEYWORDS
- routing; IP; spoof; UNIX; free.
-
- ABSTRACT
- Query allows remote viewing of a gateway's routing
- tables.
-
- MECHANISM
- Query formats and sends a RIP request or POLL command
- to a destination gateway.
-
- CAVEATS
- Query is intended to be used a a tool for debugging
- gateways, not for network management. SNMP is the pre-
- ferred protocol for network management.
-
- BUGS
- None known.
-
- LIMITATIONS
- The polled gateway must run RIP.
-
- HARDWARE REQUIRED
- No restriction.
-
- SOFTWARE REQUIRED
- 4.3BSD UNIX or related OS.
-
- AVAILABILITY
- Available with routed and gated distributions.
-
- Routed may be obtained via anonymous FTP from
- uunet.uu.net, in file bsd-
- sources/src/network/routed.tar.Z.
-
- Gated may be obtained via anonymous FTP from
- devvax.tn.cornell.edu. Distribution files are in
- directory pub/gated.
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 97]
-
- Internet Tool Catalog SERAG
-
-
- NAME
- SERAG -- the Simple Event Reporting and Alarm Genera-
- tion tool
-
- KEYWORDS
- alarm, security; ethernet, IP; NMS, proprietary; UNIX.
-
- ABSTRACT
- The Simple Event Reporting and Alarm Generation (SERAG)
- collects error messages and other event reports from
- servers on a LAN. Any node with UDP/IP can be the
- source of such messages/reports. The logging of error
- messages is integrated with the audit trail facility of
- the Network Control Server (NCS) from 3COM. Alarms are
- generated on the NCS based on predefined conditions.
- Alarms may be sent to the console of the NCS, logged in
- a file, or routed via WAN to a service center.
-
- SERAG can automatically detect a predefined set of
- errors in the servers and generate alarms. The break-
- down of a server in the LAN may also result in alarm
- generation.
-
- SERAG creates an error log that can be used for post-
- testing analysis.
-
- MECHANISM
- The tool searches through the audit trail (error log)
- files for events specified by the user. The search may
- be constrained to specific nodes in the network and to
- a specific time frame. Events may be combined into
- conditions which are logical expressions (e.g., look
- for eventA and eventB and not eventC within time frame
- so and so). This is an interactive query facility to
- analyze the audit trail (error log).
-
- The user may also ask for such conditions to be checked
- at regular intervals, and specify routing of error mes-
- sages in case the condition is satisfied. The checking
- of such conditions is done by a daemon process running
- in the background.
-
- CAVEATS
- May impact the performance of the NCS if error logs are
- big, or if conditions are computationally complex.
-
- BUGS
- None known.
-
-
-
- IETF NOCTools Working Group [Page 98]
-
- Internet Tool Catalog SERAG
-
-
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- A workstation running UNIX.
-
- SOFTWARE REQUIRED
- Implemented in C (using lex and yacc) on a Sun 3/50.
- Also runs under Xenix. Should work with most versions
- of UNIX.
-
- AVAILABILITY
- Developed jointly by ELAB-RUNIT and Norsk Data:
-
- Tor Didriksen, Ole-Hjalmar Kristensen, Steinar
- Haug,
- Eldfrid Oefsti Oevstedal, Tor Staalhane
- ELAB-RUNIT
- N-7034 Trondheim
- Norway
-
- phone: +47 7 593000
- fax : +47 7 532586
- email: didrik@idt.unit.no
- sthaug@idt.unit.no
- kristensen@vax.runit.unit.no
-
- Commercially available from:
- Norsk Data A/S
- P.O. Box 25, Bogerud
- N-0621 Oslo 6
- Norway
- ref: network management/security management/fault
- management
-
- phone: +47 2 627500
- fax : +47 2 296796
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 99]
-
- Internet Tool Catalog SMA
-
-
- NAME
- sma -- OSI System Management Agent
-
- KEYWORDS
- alarm, manager, status; OSI; UNIX; free.
-
- ABSTRACT
- The sma is a CMIP agent which runs on BSD UNIX and pro-
- vides access to management information on the operation
- of the ISODE transport layer (ISO Transport Protocol
- class 0). It also supports the sending of event
- reports. Activity can be recorded in a log file.
-
- MECHANISM
- The sma communicates with the active ISODE transport
- entities using UNIX UDP sockets in order to receive the
- management information which is made available to other
- manager processes via CMIP.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- ISODE Transport Layer only supported at present.
-
- HARDWARE REQUIRED
- Developed on Sun3, tested on Sun3 and VAXStation.
-
- SOFTWARE REQUIRED
- The ISODE protocol suite, BSD UNIX.
-
- AVAILABILITY
- The sma and related tools, known as OSIMIS (OSI Manage-
- ment Information Service), are publicly available from
- University College London, England via FTP and FTAM.
- To obtain information regarding a copy send email to
- gknight@ac.ucl.cs.uk or call +44 1 380 7366.
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 100]
-
- Internet Tool Catalog SNIFFER
-
-
- NAME
- Sniffer
-
- KEYWORDS
- analyzer, generator, traffic; DECnet, ethernet, IP,
- NFS, OSI, ring, SMTP, star; eavesdrop; standalone.
-
- ABSTRACT
- The Network General Sniffer is a protocol analyzer for
- performing LAN diagnostics, monitoring, traffic genera-
- tion, and troubleshooting. The Sniffer protocol
- analyzer has the capability of capturing every packet
- on a network and of decoding all seven layers of the
- OSI protocol model. Capture frame selection is based
- on several different filters: protocol content at lower
- levels; node addresses; pattern matching (up to 8
- logically-related patterns of 32 bytes each); and des-
- tination class. Users may extend the protocol
- interpretation capability of the Sniffer by writing
- their own customized protocol interpreters and linking
- them to the Sniffer software.
-
- The Sniffer displays network traffic information and
- performance statistics in real time, in user-selectable
- formats. Numeric station addresses are translated to
- symbolic names or manufacturer ID names. Network
- activities measured include frames accepted, Kbytes
- accepted, and buffer use. Each network version has
- additional counters for activities specific to that
- network. Network activity is expressed as
- frames/second, Kbytes/second, or per cent of network
- bandwidth utilization.
-
- Data collection by the Sniffer may be output to printer
- or stored to disk in either print-file or spread-sheet
- format.
-
- Protocol suites understood by the Sniffer include:
- Banyan Vines, IBM Token-Ring, Novell Netware, XNS/MS-
- Net (3Com 3+), DECnet, TCP/IP (including SNMP and
- applications-layer protocols such as FTP, SMTP, and
- TELNET), X Windows (for X version 11), NFS, and several
- SUN proprietary protocols (including mount, pmap, RPC,
- and YP). Supported LANs include: ethernet, Token-ring
- (4Mb and 16Mb versions), ARCNET, StarLAN, IBM PC Net-
- work (Broadband), and Apple Localtalk Network.
-
- MECHANISM
-
-
-
- IETF NOCTools Working Group [Page 101]
-
- Internet Tool Catalog SNIFFER
-
-
- The Sniffer is a self-contained, portable protocol
- analyzer that require only AC line power and connection
- to a network to operate. Normally passive (except when
- in Traffic Generator mode), it captures images of all
- or of selected frames in a working buffer, ready for
- immediate analysis and display.
-
- The Sniffer is a standalone device. Two platforms are
- available: one for use with single network topologies,
- the other for use with multi-network topologies. Both
- include Sniffer core software, a modified network
- interface card (or multiple cards), and optional proto-
- col interpreter suites.
-
- All Sniffer functions may be remotely controlled from a
- modem-connected PC. Output from the Sniffer can be
- imported to database or spreadsheet packages.
-
- CAVEATS
- In normal use, the Sniffer is a passive device, and so
- will not adversely effect network performance. Perfor-
- mance degradation will be observed, of course, if the
- Sniffer is set to Traffic Generator mode and connected
- to an active network.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- None. The Sniffer is a self-contained unit, and
- includes its own interface card. It installs into a
- network as would any normal workstation.
-
- SOFTWARE REQUIRED
- None.
-
- AVAILABILITY
- The Sniffer is available commercially. For information
- on your local representative, call or write:
-
- Network General Corporation 4200 Bohannon Drive
- Menlo Park, CA 94025 Phone: (415) 688-2700 Fax:
- 415-321-0855
-
- For acquisition by government agencies, the Sniffer is
-
-
-
- IETF NOCTools Working Group [Page 102]
-
- Internet Tool Catalog SNIFFER
-
-
- included on the GSA schedule.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 103]
-
- Internet Tool Catalog SNMP DEVELOPMENT KIT
-
-
- NAME
- The SNMP Development Kit
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX; free, sourcelib.
-
- ABSTRACT
- The SNMP Development Kit comprises C Language source
- code for a programming library that facilitates access
- to the management services of the SNMP (RFC 1098).
- Sources are also included for a few simple client
- applications whose main purpose is to illustrate the
- use of the library. Example client applications query
- remote SNMP agents in a variety of modes, and generate
- or collect SNMP traps. Code for an example SNMP agent
- that supports a subset of the Internet MIB (RFC 1066)
- is also included.
-
- MECHANISM
- The Development Kit facilitates development of SNMP-
- based management applications -- both clients and
- agents. Example applications execute SNMP management
- operations according to the values of command line
- arguments.
-
- CAVEATS
- None.
-
- BUGS
- Fixed in the next release.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- The SNMP library source code is highly portable and
- runs on a wide range of platforms.
-
- SOFTWARE REQUIRED
- The SNMP library source code has almost no operating
- system dependencies and runs in a wide range of
- environments. Certain portions of the example SNMP
- agent code are specific to the 4.3BSD implementation of
- the UNIX system for the DEC MicroVAX.
-
- AVAILABILITY
- The Development Kit is available via anonymous FTP from
- host allspice.lcs.mit.edu. The copyright for the
-
-
-
- IETF NOCTools Working Group [Page 104]
-
- Internet Tool Catalog SNMP DEVELOPMENT KIT
-
-
- Development Kit is held by the Massachusetts Institute
- of Technology, and the Kit is distributed without
- charge according to the terms set forth in its code and
- documentation. The distribution takes the form of a
- UNIX tar file.
-
- Bug reports, questions, suggestions, or complaints may
- be mailed electronically to snmp-dk@ptt.lcs.mit.edu,
- although no response in any form is guaranteed. Dis-
- tribution via UUCP mail may be arranged by contacting
- the same address. Requests for hard-copy documentation
- or copies of the distribution on magnetic media are
- never honored.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 105]
-
- Internet Tool Catalog SNMP LIBRARIES
-
-
- NAME
- Snmp Libraries and Utilities from SNMP Research.
-
- KEYWORDS
- alarm, control, manager, map, routing, status; bridge,
- DECnet, ethernet, IP, OSI, ring, star; NMS, SNMP; DOS,
- UNIX, VMS; sourcelib.
-
- ABSTRACT
- The SNMP Libraries and Utilities serve two purposes:
-
- 1) to act as building blocks for the construction of
- SNMP-based agent and manager applications; and
-
- 2) to act as network management tools for network
- fire fighting and report generation.
-
- The libraries perform ASN.1 parsing and generation
- tasks for both network management station applications
- and network management agent applications. These
- libraries hide the details of ASN.1 parsing and genera-
- tion from application writers and make it unnecessary
- for them to be expert in these areas. The libraries
- are very robust with considerable error checking
- designed in. The several command line utilities
- include applications for retrieving one or many vari-
- ables, retrieving tables, or effecting commands via the
- setting of remote network management variables.
-
- MECHANISM
- The parsing is performed via recursive descent methods.
- Messages are passed via the Simple Network Management
- Protocol (SNMP).
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 106]
-
- Internet Tool Catalog SNMP LIBRARIES
-
-
-
- HARDWARE REQUIRED
- This software has been ported to a wide range of sys-
- tems, too numerous to itemize. It includes worksta-
- tions, general purpose timesharing systems, and embed-
- ded hardware in intelligent network devices such as re-
- peaters, bridges, and routers.
-
- SOFTWARE REQUIRED
- C compiler, TCP/IP library from a variety of sources.
-
- AVAILABILITY
- This is a commercial product available under license
- from:
-
- SNMP Research
- P.O. Box 8593
- Knoxville, TN 37996-4800
- (615) 573-1434 (Voice)
- (615) 573-9197 (FAX)
- Attn: Dr. Jeff Case
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 107]
-
- Internet Tool Catalog SNMPASK
-
-
- NAME
- snmpask
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmpask is a network monitoring application which gath-
- ers specific information from a single network entity
- at regular intervals and stores this information into
- UNIX flat files. A report generation package is
- included in the NYSERNet SNMP Software Distribution to
- produce reports and graphs from the raw data.
-
- MECHANISM
- Snmpask uses SNMP to gather its information. The agent
- which must be queried and the variables to query for
- are specified in a configuration file.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpask to be useful.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- SNMP polling is done synchronously. Only a single
- agent can be polled per snmpask process. Only 16 vari-
- ables can be requested per snmpask process.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmpask is available in the NYSERNet SNMP Software Dis-
- tribution, which is licensed, copyrighted software. To
- obtain information regarding the package send mail to:
- snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 108]
-
- Internet Tool Catalog SNMPD (I)
-
-
- NAME
- snmpd
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmpd is an SNMP agent which runs on UNIX derivatives
- and answers network management queries from network
- management stations supporting SNMP. Snmpd also sup-
- ports the sending of SNMP traps.
-
- MECHANISM
- Snmpd conforms to SNMP as specified in RFC 1098. Cer-
- tain user configurable options are manipulated through
- a simple configuration file.
-
- CAVEATS
- UNIX does not support all of the MIB variables speci-
- fied in RFC 1066. Snmpd does the best it can to find
- the answers.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- See CAVEATS.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant.
-
- AVAILABILITY
- Snmpd is available in the NYSERNet SNMP Software Dis-
- tribution, which is licensed, copyrighted software. To
- obtain information regarding the package send mail to:
- snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 109]
-
- Internet Tool Catalog SNMPD (II)
-
-
- NAME
- snmpd -- an SNMP host/gateway agent daemon from SNMP
- Research.
-
- KEYWORDS
- manager, status; bridge, ethernet, IP, ring, star; NMS,
- SNMP; DOS, UNIX; sourcelib.
-
- ABSTRACT
- The snmpd agent daemon listens for and responds to net-
- work management queries and commands from logically
- remote network management stations. The agent daemon
- also emits SNMP traps to identified trap receivers.
- The agent daemon is architected to make the addition of
- additional vendor-specific variables a straight-forward
- task. The snmpd application comes complete with source
- code including a powerful set of portable libraries for
- generating and parsing SNMP messages and a set of com-
- mand line utilities.
-
- MECHANISM
- Network management variables are made available for
- inspection and/or alteration by means of the Simple
- Network Management Protocol (SNMP).
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- Only the operating system variables available without
- source code modifications to the operating system and
- device device drivers are supported.
-
- HARDWARE REQUIRED
- This software has been ported to a wide range of sys-
- tems, too numerous to itemize. It includes worksta-
- tions, general purpose timesharing systems, and embed-
- ded hardware in intelligent network devices such as
- repeaters, bridges, and routers.
-
- SOFTWARE REQUIRED
- C compiler, ".h" files for operating system.
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 110]
-
- Internet Tool Catalog SNMPD (II)
-
-
-
- AVAILABILITY
- This is a commercial product available under license
- from:
-
- SNMP Research
- P.O. Box 8593
- Knoxville, TN 37996-4800
- (615) 573-1434 (Voice)
- (615) 573-9197 (FAX)
- Attn: Dr. Jeff Case
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 111]
-
- Internet Tool Catalog SNMPLOOKUP
-
-
- NAME
- snmplookup
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmplookup is a network monitoring application that
- allows the interactive querying of a network entity.
- Snmplookup mimics nslookup, the DNS interactive query
- tool, in style and feel.
-
- MECHANISM
- Snmplookup uses SNMP to gather its information. The
- network entity to be queried and the variable to be
- retrieved can be entered from the command shell after
- snmplookup is invoked.
-
- CAVEATS
- An SNMP agent must be running on the network entity
- being monitored.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- See CAVEATS.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmplookup is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 112]
-
- Internet Tool Catalog SNMPPERFMON
-
-
- NAME
- snmpperfmon
-
- KEYWORDS
- manager, status; IP; curses, NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmpperfmon is a network monitoring application based
- on the Berkeley curses terminal graphics package and
- the Simple Network Management Protocol. The applica-
- tion monitors certain interface statistics from a sin-
- gle agent and displays them in tabular form on a stan-
- dard terminal screen.
-
- MECHANISM
- Snmpperfmon uses SNMP to gather its information. The
- agent to be queried is specified on the command line.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpperfmon to be useful.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- SNMP polling is done synchronously. Only the predeter-
- mined (read "hard coded") interface statistics can be
- displayed.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library. The "curses" library.
-
- AVAILABILITY
- Snmpperfmon is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 113]
-
- Internet Tool Catalog SNMPPOLL
-
-
- NAME
- snmppoll
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmppoll is a network monitoring application which
- gathers specific information from a network at regular
- intervals and stores this information into UNIX flat
- files. A report generation package is included in the
- NYSERNet SNMP Software Distribution to produce reports
- and graphs of raw data collected via SNMP.
-
- MECHANISM
- Snmppoll uses SNMP to gather its information. The
- agents which must be queried and the variables to query
- for are specified in a configuration file.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmppoll to be useful.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- SNMP polling is done synchronously.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmppoll is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 114]
-
- Internet Tool Catalog SNMPQUERY
-
-
- NAME
- snmpquery
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmpquery is a network monitoring application which
- allows the simple query of a single network entity from
- the command line.
-
- MECHANISM
- Snmpquery uses SNMP to gather its information. The
- entity to be monitored and the variables to be
- retrieved must be specified on the command line.
-
- CAVEATS
- An SNMP agent must be running on the network entity
- being monitored.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- Only one network entity can be managed per invocation.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmpquery is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 115]
-
- Internet Tool Catalog SNMPROUTE
-
-
- NAME
- snmproute
-
- KEYWORDS
- manager, routing; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmproute is a network monitoring application that
- allows the user to query for the entire routing table
- or a single routing table entry from a network entity.
-
- MECHANISM
- Snmproute uses SNMP to gather its information. The
- network entity to be queried and the destination net-
- work to be queried for must be specified on the command
- line.
-
- CAVEATS
- An SNMP agent must be running on the network entity
- being monitored.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- Only one network entity can be queried per invocation.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmproute is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 116]
-
- Internet Tool Catalog SNMPSET
-
-
- NAME
- snmpset
-
- KEYWORDS
- control, manager; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmpset is a network management application that allows
- the alteration of a single variable in a specific
- agent.
-
- MECHANISM
- Snmpset uses SNMP to alter the agent variables. The
- agent to which the set is directed and the variable to
- alter must be specified on the command line. The user
- is prompted before any changes are made.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being managed in order for snmpset to be useful. In
- addition, a read-write community must be configured on
- the agent.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- Only one variable can be altered per invocation.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmpset is available in the NYSERNet SNMP Software Dis-
- tribution, which is licensed, copyrighted software. To
- obtain information regarding the package send mail to:
- snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 117]
-
- Internet Tool Catalog SNMPSRC
-
-
- NAME
- snmpsrc
-
- KEYWORDS
- manager, routing; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmpsrc is a network monitoring application that starts
- at a specified router in the network and traces the
- path of a given destination network from the starting
- router.
-
- MECHANISM
- Snmpsrc uses SNMP to gather its information. The
- starting router and destination network must be speci-
- fied on the command line.
-
- CAVEATS
- An SNMP agent must be running on all of the routers in
- the path to the destination network in order for a com-
- plete path to be reported back to the user. The same
- SNMP community must also be configured in every SNMP
- agent in the path to the destination network.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- See CAVEATS.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmpsrc is available in the NYSERNet SNMP Software Dis-
- tribution, which is licensed, copyrighted software. To
- obtain information regarding the package send mail to:
- snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 118]
-
- Internet Tool Catalog SNMPSTAT
-
-
- NAME
- snmpstat
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmpstat is a network monitoring application that gath-
- ers specific information from a network at regular
- intervals and stores this information into a commercial
- database. A report generation package is included in
- the NYSERNet SNMP Software Distribution to produce
- reports and graphs of raw data collected via SNMP.
-
- MECHANISM
- Snmpstat uses SNMP to gather its information. The
- agents which must be queried and the variables to query
- for are specified in a configuration file.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpstat to be useful.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- SNMP polling is done synchronously. Currently, Ingres
- is the only commercial database supported. SQL is the
- query language being used.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmpstat is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 119]
-
- Internet Tool Catalog SNMPTRAPD
-
-
- NAME
- snmptrapd
-
- KEYWORDS
- alarm, manager; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmptrapd is an SNMP trap agent that runs on UNIX
- derivatives. It receives and logs traps which are gen-
- erated from snmp agents. A report generation package
- is included in the NYSERNet SNMP Software Distribution
- to produce reports and graphs of raw data collected via
- SNMP.
-
- MECHANISM
- Snmptrapd conforms to SNMP as specified in RFC 1098.
- Certain user configurable options are manipulated
- through a simple configuration file.
-
- CAVEATS
- None.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- Snmptrapd only logs traps into a UNIX flat file.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant.
-
- AVAILABILITY
- Snmptrapd is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 120]
-
- Internet Tool Catalog SNMPWATCH
-
-
- NAME
- snmpwatch
-
- KEYWORDS
- manager, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Snmpwatch is a network monitoring application that mon-
- itors variables in a single network entity and reports
- when they have changed value.
-
- MECHANISM
- Snmpwatch uses SNMP to gather its information. The
- entity to be monitored and the variables to be watched
- must be specified on the command line. Once a value
- changes, snmpwatch prints out the value and the vari-
- able to the standard output.
-
- CAVEATS
- An SNMP agent must be running on the network entity
- being monitored. Upon invocation, the initial value of
- each variable will printed out to the standard output.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- Only one network entity can be managed per invocation.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library.
-
- AVAILABILITY
- Snmpwatch is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 121]
-
- Internet Tool Catalog SNMPXBAR
-
-
- NAME
- snmpxbar
-
- KEYWORDS
- manager, status; IP; NMS, SNMP, X; UNIX.
-
- ABSTRACT
- Snmpxbar is a network monitoring application based on
- X-Windows Version 11 Release 2 and the Simple Network
- Management Protocol. The application monitors a single
- numeric MIB object and displays its value in a bar
- chart. Snmpxbar supports color graphics.
-
- MECHANISM
- Snmpxbar uses SNMP to gather its information. The MIB
- object to be graphed must be specified on the command
- line. The polling interval can be changed dynamically
- from within snmpxbar.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpxbar to be useful.
-
- BUGS
- Bugs are fixed as reports come in. Report bugs to:
- nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- Can only graph one numeric MIB object per invocation.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library. X-Windows.
-
- AVAILABILITY
- Snmpxbar is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 122]
-
- Internet Tool Catalog SNMPXCONN
-
-
- NAME
- snmpxconn
-
- KEYWORDS
- manager, map, status; IP; NMS, SNMP, X; UNIX.
-
- ABSTRACT
- Snmpxconn is a network monitoring application based on
- X-Windows Version 11 Release 2 and the Simple Network
- Management Protocol. The application monitors a number
- of (configurable) network entities and graphically dep-
- icts the TCP connections associated with the network
- entities via a TCP topology map.
-
- MECHANISM
- Snmpxconn uses SNMP to gather its information. A con-
- figuration file is used to determine the network enti-
- ties to be monitored. There are certain command line
- arguments which manipulate the X environment and SNMP
- actions.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpxconn to be useful.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- SNMP polling is done synchronously. The network enti-
- ties must be configured by manually adding information
- to a configuration file.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library. X-Windows.
-
- AVAILABILITY
- Snmpxconn is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
- IETF NOCTools Working Group [Page 123]
-
- Internet Tool Catalog SNMPXMON
-
-
- NAME
- snmpxmon
-
- KEYWORDS
- manager, map, status; IP; NMS, SNMP, X; UNIX.
-
- ABSTRACT
- Snmpxmon is a network monitoring application based on
- X-Windows Version 11 Release 2 and the Simple Network
- Management Protocol. This application will determine
- the status of sites and links it is configured to moni-
- tor (via its configuration file) by querying the desig-
- nated sites and then displaying the result in a map
- form. Snmpxmon supports color graphics.
-
- MECHANISM
- Snmpxmon uses SNMP to gather its information. A confi-
- guration file is used to design the topology map.
- There are certain command line arguments which manipu-
- late the X environment and SNMP actions.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpxmon to be useful.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- SNMP polling is done synchronously. The topology map
- must be configured by hand.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library. X-Windows.
-
- AVAILABILITY
- Snmpxmon is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
- IETF NOCTools Working Group [Page 124]
-
- Internet Tool Catalog SNMPXPERF
-
-
- NAME
- snmpxperf
-
- KEYWORDS
- manager, status; IP; NMS, SNMP, X; UNIX.
-
- ABSTRACT
- Snmpxperf is a network monitoring application based on
- X-Windows Version 11 Release 2 and the Simple Network
- Management Protocol. The application monitors a single
- numeric MIB object and displays its value in an EKG
- style histogram. Snmpxperf supports color graphics.
-
- MECHANISM
- Snmpxperf uses SNMP to gather its information. The MIB
- object to be graphed must be specified on the command
- line. The polling interval can be changed dynamically
- from within snmpxperf.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpxperf to be useful.
-
- BUGS
- Auto-scaling sometimes doesn't downscale the EKG-graph
- enough on large spikes. This results in some of the
- graph running into the button boxes at the top of the
- window. Generally, Bugs are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- Can only graph one numeric MIB object per invocation.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library. X-Windows.
-
- AVAILABILITY
- Snmpxperf is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
-
-
- IETF NOCTools Working Group [Page 125]
-
- Internet Tool Catalog SNMPXPERFMON
-
-
- NAME
- snmpxperfmon
-
- KEYWORDS
- manager, status, traffic; IP; NMS, SNMP, X; UNIX.
-
- ABSTRACT
- Snmpxperfmon is a network monitoring application based
- on X-Windows Version 11 Release 2 and the Simple Net-
- work Management Protocol. The application monitors a
- single Network Entity and displays graphical informa-
- tion pertaining to the entities interface traffic
- statistics. Snmpxperfmon supports color graphics.
-
- MECHANISM
- Snmpxperfmon uses SNMP to gather its information. The
- MIB agent to be polled must be specified on the command
- line. The agent is then queried about all of its
- interfaces. Four EKG-style graphs are constructed for
- each interface (input pkts, output pkts, input Octets,
- output Octets).
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpxperfmon to be useful.
-
- BUGS
- Generally, bugs are fixed as reports come in. Report
- bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- Can only graph one network entity per invocation. Can
- only graph the amount of interfaces which will fit on a
- single bitmap display. Does not auto-scale or resize.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library. X-Windows.
-
- AVAILABILITY
- Snmpxperfmon is available in the NYSERNet SNMP Software
- Distribution, which is licensed, copyrighted software.
- To obtain information regarding the package send mail
- to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
-
-
-
- IETF NOCTools Working Group [Page 126]
-
- Internet Tool Catalog SNMPXPERFMON
-
-
- NAME
- snmpxrtmetric
-
- KEYWORDS
- manager, routing; IP; NMS, SNMP, X; UNIX.
-
- ABSTRACT
- Snmpxrtmetric is a network monitoring application based
- on X-Windows Version 11 Release 2 and the Simple Net-
- work Management Protocol. The application monitors the
- routing table of a specific agent and displays the RIP
- routing metric of certain destination networks in bar
- chart format.
-
- MECHANISM
- Snmpxrtmetric uses SNMP to gather its information. A
- configuration file is used to determine which destina-
- tion networks will be graphed. The agent to be queried
- is specified on the command line. Snmpxrtmetrtic sup-
- ports color graphics.
-
- CAVEATS
- An SNMP agent must be running in the network entity
- being monitored in order for snmpxrtmetric to be use-
- ful.
-
- BUGS
- None outstanding. They are fixed as reports come in.
- Report bugs to: nysersnmp@nisc.nyser.net
-
- LIMITATIONS
- SNMP polling is done synchronously. The destination
- networks must be configured by manually adding informa-
- tion to a configuration file.
-
- HARDWARE REQUIRED
- Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
- tion I, DECstation, and a Solbourne 4/802.
-
- SOFTWARE REQUIRED
- Some UNIX variant or some other OS with a Berkeley
- Socket Compatibility Library. The X window system.
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 127]
-
- Internet Tool Catalog SNMPXRTMETRIC
-
-
-
- AVAILABILITY
- Snmpxrtmetric is available in the NYSERNet SNMP
- Software Distribution, which is licensed, copyrighted
- software. To obtain information regarding the package
- send mail to: snmplisc@nisc.nyser.net or call +1 518-
- 283-8860.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 128]
-
- Internet Tool Catalog SPIDERMONITOR
-
-
- NAME
- SpiderMonitor P220, K220 and
- SpiderAnalyzer P320, K320
-
- KEYWORDS
- alarm, analyzer, generator, traffic; DECnet, ethernet,
- IP, OSI; eavesdrop; standalone; sourcelib.
-
- ABSTRACT
- The SpiderMonitor and SpiderAnalyzer are protocol
- analyzers for performing ethernet LAN diagnostics, mon-
- itoring, traffic generation, and troubleshooting. The
- SpiderMonitor has the capability of capturing every
- packet on a network and of decoding the first four
- layers of the OSI protocol model. The SpiderAnalyzer
- has additional software for decoding higher protocol
- layers. Protocol suites understood: TCP/IP (including
- SNMP and applications-layer protocols), OSI, XNS, DEC-
- net and IPX. User-definable decodes can be written in
- 'C' with the Microsoft version 5.0 'C' compiler. A
- decode guide is provided.
-
- The SpiderAnalyzer supports multiple simultaneous
- filters for capturing packets using predefined patterns
- and error states. Filter patterns can also trigger on
- NOT matching 1 or more filters, an alarm, or a speci-
- fied time.
-
- The SpiderAnalyzer can also employ TDR (Time Domain
- Reflectometry) to find media faults, open or short cir-
- cuits, or transceiver faults. It can transmit OSI,
- XNS, and Xerox link-level echo packets to user-
- specified stations, performs loop round tests.
-
- In traffic generation mode, the SpiderAnalyzer has the
- ability to generate packets at random intervals of ran-
- dom lengths or any combination of random or fixed
- interval or length, generation of packets with CRC
- errors, or packets that are too short, or packets that
- are too long.
-
- Output from the SpiderMonitor/Analyzer can be imported
- to database or spreadsheet packages.
-
- MECHANISM
- The SpiderMonitor and Spider Analyzer are available as
- stand-alone, IBM PC compatible packages based upon a
- Compaq III portable system, or as a plug-in boards for
-
-
-
- IETF NOCTools Working Group [Page 129]
-
- Internet Tool Catalog SPIDERMONITOR
-
-
- any IBM XT/AT compatible machine. The model 220 (Spi-
- derMonitor) systems provide a functional base suited
- for most network management needs. The model 320 (Spi-
- derAnalyzer) systems provide extended functionality in
- the development mode and traffic generation mode as
- well more filtering capabilities than the 220 models.
-
- CAVEATS
- Traffic generation will congest an operational ether-
- net.
-
- BUGS
- None known.
-
- LIMITATIONS
- Monitoring of up to 1024 stations and buffering of up
- to 1500 packets. The model 220 provides for 3 filters
- with a filter depth of 46 bytes. The model 320 pro-
- vides for 4 filters and a second level of filtering
- with a filter depth of 64 bytes.
-
- HARDWARE REQUIRED
- PX20s are self contained, the KX20s require an IBM
- PC/XT-AT compatible machine with 5 megabytes of hard
- disk storage and the spare slot into which the board
- kit is plugged.
-
- SOFTWARE REQUIRED
- None. The SpiderAnalyzer requires the Microsoft 'C'
- Compiler, Version 5.0 for writing user defined decodes.
-
- AVAILABILITY
- The SpiderMonitor/Analyzer is available commercially.
- For information on your local representative, call or
- write:
-
- Spider Systems, Inc.
- 12 New England Executive Park
- Burlington, MA 01803
- Telephone: 617-270-3510
- FAX: 617-270-9818
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 130]
-
- Internet Tool Catalog SPIMS
-
-
- NAME
- SPIMS -- the Swedish Institute of Computer Science
- (SICS) Protocol Implementation Measurement System tool.
-
- KEYWORDS
- benchmark, debugger; IP, OSI; spoof; UNIX.
-
- ABSTRACT
- SPIMS is used to measure the performance of protocol
- and "protocol-like" services including response time
- (two-way delay), throughput and the time to open and
- close connections. It has been used to:
-
- o+ benchmark alternative protocol implementations,
-
- o+ observe how performance varies when parameters in
- specific implementations have been varied (i.e.,
- to tune parameters).
-
- SPIMS currently has interfaces to the DoD Internet Pro-
- tocols: UDP, TCP, FTP, SunRPC, the OSI protocols from
- the ISODE 4.0 distribution package: FTAM, ROSE, ISO TP0
- and to Sunlink 5.2 ISO TP4 as well as Stanford's VMTP.
- Also available are a rudimentary set of benchmarks,
- stubs for new protocol interfaces and a user manual.
- For an example of the use of SPIMS to tune protocols,
- see:
- Nordmark & Cheriton, "Experiences from VMTP: How
- to achieve low response time," _I_F_I_P _W_G_6._1/_6._4:
- _P_r_o_t_o_c_o_l_s _f_o_r _H_i_g_h-_S_p_e_e_d _N_e_t_w_o_r_k_s, May 1989,
- Zurich. To be published.
-
- MECHANISM
-
- SPIMS runs as user processes and uses a TCP connection
- for measurement set-up. Measurements take place
- between processes over the measured protocol. SPIMS
- generates messages and transfers them via the measured
- protocol service according to a user-supplied specifi-
- cation. SPIMS has a unique measurement specification
- language that is used to specify a measurement session.
- In the language there are constructs for different
- application types (e.g., bulk data transfer), for
- specifying frequency and sequence of messages, for dis-
- tribution over message sizes and for combining basic
- specifications. These specifications are independent
- of both protocols and protocol implementations and can
- be used for benchmarking. For more details on the
-
-
-
- IETF NOCTools Working Group [Page 131]
-
- Internet Tool Catalog SPIMS
-
-
- internals of SPIMS, see:
- Nordmark & Gunningberg, "SPIMS: A Tool for Proto-
- col Implementation Performance Measurements" _P_r_o_c.
- _o_f _1_3:_t_h _C_o_n_f. _o_n _L_o_c_a_l _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_s, Min-
- neapolis 1989, pp 222-229.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- SPIMS is implemented on UNIX, including SunOS 4.,
- 4.3BSD UNIX, DN (UNIX System V, with extensions) and
- Ultrix 2.0/3.0. It requires a TCP connection for meas-
- urement set-up. No kernel modifications or any modifi-
- cations to measured protocols are required.
-
- AVAILABILITY
- SPIMS is not in the public domain; the software is
- covered by licenses. The Swedish Institute of Computer
- Science has released the research prototype of SPIMS
- for research and non-commercial use. Commercial organ-
- izations may obtain the research prototype, but it is
- for internal research only and for no commercial use
- whatsoever. A commercial, supported version of SPIMS is
- distributed by TeleLOGIC Uppsala AB, Sweden.
-
- For universities and non-profit organizations, SPIMS
- source code is distributed free of charge. There are
- two ways to get the software:
-
- 1. FTP. If you have an Internet FTP connection, you
- can use anonymous FTP to sics.se [192.16.123.90],
- and retrieve the file in pub/spims-
- dist/dist890915.tar.Z (this is a .6MB tar image)
- in BINARY mode. Log in as user anonymous and at
- the password prompt, use your complete electronic
- mail address.
-
- 2. On a Sun 1/4-inch cartridge tape. For mailing, a
-
-
-
- IETF NOCTools Working Group [Page 132]
-
- Internet Tool Catalog SPIMS
-
-
- handling fee of US$150.00 will be charged. Submit
- a bank check with the request. Do not send tapes
- or envelopes.
-
- For other organizations, the SPIMS source code for the
- research prototype is distributed for a one-time fee of
- US$500.00. Organizations interested in the research
- prototype need to contact SICS via email and briefly
- motivate why they qualify (non-commercial use) for the
- research prototype. They will thereafter get a permis-
- sion to obtain a copy from the same distribution source
- as for universities.
-
- For more information about the research prototype dis-
- tribution, contact:
-
- Swedish Institute of Computer Science
- Att: Birgitta Klingenberg
- P.O. Box 1263
- S-164 28 Kista
- SWEDEN
-
- e-address: spims@sics.se
- Phone: +46-8-7521500, Fax: +46-8-7517230
-
- TeleLOGIC Uppsala AB, a subsidiary of Swedish Telecom,
- distributes and supports a version of SPIMS for commer-
- cial use. It consists of object code for SunOS 4.,
- 4.3BSD UNIX, DNIX, and Ultrix 2.0/3.0. Support for
- other UNIX-like implementations will be considered
- according to demand. The same interfaces to the DoD
- Internet and OSI protocols from the ISODE 4.0 are
- included as well as a user manual.
-
- For further information about SPIMS for the commercial
- user please contact:
- Claes Hojenberg
- TeleLOGIC Uppsala AB
- P.O. Box 1218
- S-751 42 UPPSALA
- Sweden
-
- e-address: claes@uplog.se
- Phone: +46-18-189400, Fax: +46-18-132039
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 133]
-
- Internet Tool Catalog SPRAY
-
-
- NAME
- spray
-
- KEYWORDS
- benchmark, generator; IP; ping; UNIX.
-
- ABSTRACT
- Spray is a traffic generation tool that generates RPC
- or UDP packets, or ICMP Echo Requests. The packets are
- sent to a remote procedure call application at the des-
- tination host. The count of received packets is
- retrieved from the remote application after a certain
- number of packets have been transmitted. The differ-
- ence in packets received versus packets sent represents
- (on a LAN) the packets that the destination host had to
- drop due to increasing queue length. A measure of
- throughput relative to system speed and network load
- can thus be obtained.
-
- MECHANISM
- See above.
-
- CAVEATS
- Spray can congest a network.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- SunOS
-
- AVAILABILITY
- Supplied with SunOS.
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 134]
-
- Internet Tool Catalog TCPDUMP
-
-
- NAME
- tcpdump
-
- KEYWORDS
- traffic; ethernet, IP, NFS; UNIX, VMS; free.
-
- ABSTRACT
- Tcpdump can interpret and print headers for the follow-
- ing protocols: ethernet, IP, ICMP, TCP, UDP, NFS, ND,
- ARP/RARP, AppleTalk. Tcpdump has proven useful for
- examining and evaluating the retransmission and window
- management operations of TCP implementations.
-
- MECHANISM
- Much like etherfind, tcpdump writes a log file of the
- frames traversing an ethernet interface. Each output
- line includes the time a packet is received, the type
- of packet, and various values from its header.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- Public domain version requires a kernel patch for
- SunOS.
-
- HARDWARE REQUIRED
- Ethernet.
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS, or VMS.
-
- AVAILABILITY
- Available, though subject to copyright restrictions,
- via anonymous FTP from ftp.ee.lbl.gov. The source and
- documentation for the tool is in compressed tar format,
- in file tcpdump.tar.Z. Also available from
- spam.itstd.sri.com, in directory pub. For VMS hosts
- with DEC ethernet controllers, available as part of TGV
- MultiNet IP software package.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 135]
-
- Internet Tool Catalog TCPLOGGER
-
-
- NAME
- tcplogger
-
- KEYWORDS
- traffic; IP; eavesdrop; UNIX; free.
-
- ABSTRACT
- Tcplogger consists of modifications to the 4.3BSD UNIX
- source code, and a large library of post-processing
- software. Tcplogger records timestamped information
- from TCP and IP packets that are sent and received on a
- specified connection. For each TCP packet, information
- such as sequence number, acknowledgement sequence
- number, packet size, and header flags is recorded. For
- an IP packet, header length, packet length and TTL
- values are recorded. Customized use of the TCP option
- field allows the detection of lost or duplicate pack-
- ets.
-
- MECHANISM
- Routines of 4.3BSD UNIX in the netinet directory have
- been modified to append information to a log in memory.
- The log is read continuously by a user process and
- written to a file. A TCP option has been added to
- start the logging of a connection. Lots of post-
- processing software has been written to analyze the
- data.
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- To get a log at both ends of the connection, the modi-
- fied kernel should be run at both the hosts.
-
- All connections are logged in a single file, but
- software is provided to filter out the record of a sin-
- gle connection.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- 4.3BSD UNIX (as modified for this tool).
-
-
-
-
- IETF NOCTools Working Group [Page 136]
-
- Internet Tool Catalog TCPLOGGER
-
-
-
- AVAILABILITY
- Free, although a 4.3BSD license is required. Contact
- Olafur Gudmundsson (ogud@cs.umd.edu).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 137]
-
- Internet Tool Catalog TOKENVIEW
-
-
- NAME
- TokenVIEW
-
- KEYWORDS
- control, manager, status; ring; NMS, proprietary; DOS.
-
- ABSTRACT
- Network Management tool for 4/16 Mbit IEEE 802.5 Token
- Ring Networks. Monitors active nodes and ring errors.
- Maintains database of nodes, wire centers and their
- connections. Separate network management ring allows
- remote configuration of wire centers.
-
- MECHANISM
- A separate network management ring used with Proteon
- Intelligent Wire Centers allows wire center configura-
- tion information to be read and modified from a single
- remote workstation. A log of network events used with
- a database contain nodes, wire centers and their con-
- nections, facilitates tracking and correction of net-
- work errors. Requires an "E" series PROM, sold with
- package.
-
- CAVEATS
- Currently, only ISA bus cards support the required E
- series PROM.
-
- BUGS
- None known.
-
- LIMITATIONS
- 256 nodes, 1 net.
-
- HARDWARE REQUIRED
- 512K RAM, CGA or better, hard disk, mouse supported.
-
- SOFTWARE REQUIRED
- MS-DOS, optional mouse driver
-
- AVAILABILITY
- Fully supported product of Proteon, Inc. Previously
- sold as Advanced Network Manager (ANM). For more in-
- formation, contact:
- Proteon, Inc. Phone: (508) 898-2800
- 2 Technology Drive Fax: (508) 366-8901
- Westborough, MA 01581 Telex: 928124
-
-
-
-
-
- IETF NOCTools Working Group [Page 138]
-
- Internet Tool Catalog TRACEROUTE
-
-
- NAME
- traceroute
-
- KEYWORDS
- routing; IP; ping; UNIX, VMS; free.
-
- ABSTRACT
- Traceroute is a tool that allows the route taken by
- packets from source to destination to be discovered.
- It can be used for situations where the IP record route
- option would fail, such as intermediate gateways dis-
- carding packets, routes that exceed the capacity of an
- datagram, or intermediate IP implementations that don't
- support record route. Round trip delays between the
- source and intermediate gateways are also reported
- allowing the determination of individual gateways con-
- tribution to end-to-end delay.
-
- Enhanced versions of traceroute have been developed
- that allow specification of loose source routes for
- datagrams. This allows one to investigate the return
- path from remote machines back to the local host.
-
- MECHANISM
- Traceroute relies on the ICMP TIME_EXCEEDED error
- reporting mechanism. When an IP packet is received by
- an gateway with a time-to-live value of 0, an ICMP
- packet is sent to the host which generated the packet.
- By sending packets to a destination with a TTL of 0,
- the next hop can be identified as the source of the
- ICMP TIME EXCEEDED message. By incrementing the TTL
- field the subsequent hops can be identified. Each
- packet sent out is also time stamped. The time stamp
- is returned as part of the ICMP packet so a round trip
- delay can be calculated.
-
- CAVEATS
- Some IP implementations forward packets with a TTL of
- 0, thus escaping identification. Others use the TTL
- field in the arriving packet as the TTL for the ICMP
- error reply, which delays identification.
-
- Sending datagrams with the source route option will
- cause some gateways to crash. It is considered poor
- form to repeat this behavior.
-
- BUGS
- None known.
-
-
-
- IETF NOCTools Working Group [Page 139]
-
- Internet Tool Catalog TRACEROUTE
-
-
-
- LIMITATIONS
- Most versions of UNIX have errors in the raw IP code
- that require kernel mods for the standard version of
- traceroute to work. A version of traceroute exists
- that runs without kernel mods under SunOS 3.5 (see
- below), but it only operates over an ethernet inter-
- face.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS, or VMS.
-
- AVAILABILITY
- Available by anonymous FTP from ftp.ee.lbl.gov, in file
- traceroute.tar.Z. It is also available from
- uc.msc.umn.edu.
-
- A version of traceroute that supports Loose Source
- Record Route, along with the source code of the
- required kernel modifications and a Makefile for
- installing them, is available via anonymous FTP from
- zerkalo.harvard.edu, in directory pub, file
- traceroute_pkg.tar.Z.
-
- A version of traceroute that runs under SunOS 3.5 and
- does NOT require kernel mods is available via anonymous
- FTP from dopey.cs.unc.edu, in file
- ~ftp/pub/traceroute.tar.Z.
-
- For VMS, traceroute is available as part of TGV Mul-
- tiNet IP software package.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 140]
-
- Internet Tool Catalog TRPT
-
-
- NAME
- TRPT -- transliterate protocol trace
-
- KEYWORDS
- traffic; IP; eavesdrop; UNIX; free.
-
- ABSTRACT
- TRPT displays a trace of a TCP socket events. When no
- options are supplied, TRPT prints all the trace records
- found in a system, grouped according to TCP connection
- protocol control block (PCB).
-
- An example of TRPT output is:
-
- 38241 ESTABLISHED:input
- [e0531003..e0531203)@6cc5b402(win=4000)<ACK> -> ESTA-
- BLISHED
- 38241 ESTABLISHED:user RCVD -> ESTABLISHED
- 38266 ESTABLISHED:output
- 6cc5b402@e0531203(win=4000)<ACK> -> ESTABLISHED
- 38331 ESTABLISHED:input
- [e0531203..e0531403)@6cc5b402(win=4000)<ACK,FIN,PUSH>
- -> CLOSE_WAIT
- 38331 CLOSE_WAIT:output
- 6cc5b402@e0531404(win=3dff)<ACK> -> CLOSE_WAIT
- 38331 CLOSE_WAIT:user RCVD -> CLOSE_WAIT
- 38343 LAST_ACK:output
- 6cc5b402@e0531404(win=4000)<ACK,FIN> -> LAST_ACK
- 38343 CLOSE_WAIT:user DISCONNECT -> LAST_ACK
- 38343 LAST_ACK:user DETACH -> LAST_ACK
-
- MECHANISM
- TRPT interrogates the buffer of TCP trace records that
- is created when a TCP socket is marked for debugging.
-
- CAVEATS
- Prior to using TRPT, an analyst should take steps to
- isolate the problem connection and find the address of
- its protocol control blocks.
-
- BUGS
- None reported.
-
- LIMITATIONS
- A socket must have the debugging option set for TRPT to
- operate. Another problem is that the output format of
- TRPT is difficult.
-
-
-
-
- IETF NOCTools Working Group [Page 141]
-
- Internet Tool Catalog TRPT
-
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS.
-
- AVAILABILITY
- Included with BSD and SunOS distributions. Available
- via anonymous FTP from uunet.uu.net, in file bsd-
- sources/src/etc/trpt.tar.Z.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 142]
-
- Internet Tool Catalog TTCP
-
-
- NAME
- TTCP
-
- KEYWORDS
- benchmark, generator; IP; ping; UNIX, VMS; free.
-
- ABSTRACT
- TTCP is a traffic generator that can be used for test-
- ing end-to-end throughput. It is good for evaluating
- TCP/IP implementations.
-
- MECHANISM
- Cooperating processes are started on two hosts. The
- open a TCP connection and transfer a high volume of
- data. Delay and throughput are calculated.
-
- CAVEATS
- Will greatly increase system load.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- No restrictions.
-
- SOFTWARE REQUIRED
- BSD UNIX or related OS, or VMS.
-
- AVAILABILITY
- Source for BSD UNIX is available via anonymous FTP from
- vgr.brl.mil, in file ftp/pub/ttcp.c, and from sgi.com,
- in file sgi/src/ttcp.c. A version of TTCP has also
- been submitted to the USENET news group
- comp.sources.unix. For VMS, ttcp.c is included in the
- MultiNet Programmer's Kit, a standard feature of TGV
- MultiNet IP software package.
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 143]
-
- Internet Tool Catalog UNISYS NCC
-
-
- NAME
- Unisys Network Control Center (NCC)
-
- KEYWORDS
- alarm, benchmark, control, generator, manager, map,
- reference, status, traffic; ethernet, FDDI, IP; NMS,
- ping, SNMP; UNIX.
-
- ABSTRACT
- The Unisys Defense Systems Network Control Center (NCC)
- provides high-performance software to support the
- management and control of TCP/IP-based networks. The
- network management system uses the Simple Network
- Management Protocol (SNMP) to exchange management
- information between the NCC and network devices. The
- NCC supports the Management Information Base (MIB)
- [RFC-1066] and the Structure and Identification of
- Management Information for TCP/IP-based Internets
- [RFC-1065]. In addition, Unisys has extended the MIB
- definitions to support the features of Unisys FDDI LAN
- devices, such as the FDDI Smart Concentrators, the FDDI
- Host Network Front Ends, and the Remote FDDI, FDDI-to-
- LAN, and FDDI-to-DDN gateways.
-
- The NCC supports seven applications. The network
- topology map displays the physical and logical maps of
- the network. The configuration management tool sup-
- ports the modification and validation of network device
- configuration data as well as the modification of MIB
- configuration data. The performance monitoring tool
- supports the collection and analysis of statistical
- parameters from network devices. The status monitoring
- tool reports on the up/down status and responsiveness
- of network devices using ICMP. The accounting tool is
- used to collect, store, and display user job activity
- at the subscriber hosts. The NCC database entry sup-
- ports RFC 1066 object definitions and Unisys-specific
- object definitions to support the Unisys FDDI devices.
- And finally, the trap reporting tool reports the
- arrival of error and event notifications using UDP
- datagrams. The NCC supports all the trap messages
- defined in RFC 1098.
-
- MECHANISM
- The NCC is based on the Simple Network Management Pro-
- tocol (SNMP).
-
-
-
-
-
- IETF NOCTools Working Group [Page 144]
-
- Internet Tool Catalog UNISYS NCC
-
-
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- A minimal platform consists of a Sun 3/60FC-8, with at
- least 200 MB disk and cartridge tape (1/4"). A full-
- sized color monitor, more disk, and a workstation based
- on a higher performance processor is beneficial to NCC
- activities.
-
- SOFTWARE REQUIRED
- SunOS Version 4.0 running the SunView windowing en-
- vironment and the SYBASE Relational Data Base Manage-
- ment System.
-
- AVAILABILITY
- Commercially available as a turn-key package or as a
- software product from:
- Unisys Defense Systems
- 5151 Camino Ruiz
- Camarillo, California 93010
- (805) 987-6811
- (Dale Russell <dsr@cam.unisys.com>)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 145]
-
- Internet Tool Catalog WIN/MGT STATION
-
-
- NAME
- WIN/MGT Station -- Network Management Station for
- SunOS.
-
- KEYWORDS
- alarm, control, manager, routing, status, traffic; eth-
- ernet, IP; NMS, SNMP, X; UNIX; library.
-
- ABSTRACT
- WIN/MGT Station for SunOS is a network management
- software product based on the SNMP. It provides the
- capability to manage standards-based networking pro-
- ducts from The Wollongong Group as well as other ven-
- dors. Fully compliant with RFCs 1065, 1066 and 1098,
- WIN/MGT Station uses a menu-driven graphical user
- interface.
-
- WIN/MGT capabilities include configuration, performance
- and fault management for SNMP-based agents. The
- WIN/MGT station can perform polling to monitor the
- status of all MIB variables defined in RFC 1066,
- "Management Information Base for network management of
- TCP/IP-based internets." In addition, the WIN/MGT Sta-
- tion can process "trap" messages from SNMP agents.
- Furthermore, the WIN/MGT Station can support any
- private extension to the Management Information Base
- with minimal user configuration.
-
- An icon-driven network interface map allows the user to
- monitor their network topology and status. Changes in
- the operational status of any manageable network ele-
- ment is displayed visually and audibly.
-
- The WIN/MGT package includes an Applications Program-
- ming Interface (API) for the "C" language. The API is
- a set of libraries that enable an applications program
- to perform SNMP "set" and "get" operations. This
- allows users to integrate site-specific applications
- with WIN/MGT.
-
- SNMP agent software for the Sun 3 host is also provided
- so that the Network Management Station itself can also
- be monitored and managed.
-
- MECHANISM
- The WIN/MGT Station uses SNMP to monitor and control
- SNMP agents.
-
-
-
-
- IETF NOCTools Working Group [Page 146]
-
- Internet Tool Catalog WIN/MGT STATION
-
-
- CAVEATS
- None.
-
- BUGS
- None known.
-
- LIMITATIONS
- A theoretical limitation of approximately 18,000 net-
- work elements can be managed.
-
- HARDWARE REQUIRED
- Any model of Sun 3 system. Recommended minimums
- include 8 MB RAM, 100 MB disk space (30 MB to start),
- and color monitor. Also tested on DECstation 3100,
- PS/2 (with SCO UNIX) and Macintosh IIcx computer using
- A/UX.
-
- SOFTWARE REQUIRED
- SunOS 4.x. MIT X Window System, Release 11, version 3,
- or OpenWindows (X.11/NeWS) from Sun Microsystems, Inc.
- WIN/MGT Station for SunOS is provided on 1/4" tape in
- cpio format.
-
- AVAILABILITY
- A commercial product of:
- The Wollongong Group, Inc.
- 1129 San Antonio Rd.
- Palo Alto, CA 94303
- (415) 962-7200 br fax (415) 968-3619
- internet oldera@twg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 147]
-
- Internet Tool Catalog XNETMON (I)
-
-
- NAME
- xnetmon, xpmon
-
- KEYWORDS
- alarm, manager, map, status; IP; NMS, SNMP; UNIX.
-
- ABSTRACT
- Xnetmon and xpmon provide graphical representation of
- performance and status of SNMP-capable network ele-
- ments. Xnetmon presents a schematic network map
- representing the up/down status of network elements;
- xpmon draws a pen plot style graph of the change over
- time of any arbitrary MIB object (RFC1066). Both xnet-
- mon and xpmon use the SNMP (RFC1098) for retrieving
- status and performance data.
-
- MECHANISM
- Xnetmon polls network elements for the status of their
- interfaces on a controllable polling interval. Pop-up
- windows displaying the values of any MIB variable are
- supported by separate polls. When SNMP traps are
- received from a network element, that element and all
- adjacent elements are immediately re-polled to update
- their status. The layout of the network map is stati-
- cally configured. Xpmon repeatedly polls (using SNMP)
- the designated network element for the value of the
- designated MIB variable on the user-specified interval.
- The change in the variable is then plotted on the strip
- chart. The strip chart regularly adjusts its scale to
- the current maximum value on the graph.
-
- CAVEATS
- Polling intervals should be chosen with care so as not
- to affect system performance adversely.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- Distributed and supported for Sun-3 systems.
-
- SOFTWARE REQUIRED
- SunOS 3.5 or 4.x; X11, release 2 or 3.
-
-
-
-
-
- IETF NOCTools Working Group [Page 148]
-
- Internet Tool Catalog XNETMON (I)
-
-
-
- AVAILABILITY
- Commercial product of:
- Wellfleet Communications, Inc.
- 12 DeAngelo Drive
- Bedford, MA 01730-2204
- (617) 275-2400
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 149]
-
- Internet Tool Catalog XNETMON (II)
-
-
- NAME
- XNETMON -- an X windows based SNMP network management
- station from SNMP Research.
-
- KEYWORDS
- alarm, control, manager, map, routing, security,
- status; DECnet, ethernet, IP, OSI, ring, star; NMS,
- SNMP, X; DOS, UNIX, VMS; sourcelib.
-
- ABSTRACT
- The XNETMON application implements a powerful network
- management station based on the X window system. It
- provides network managers tools for fault management,
- configuration management, performance management, and
- security management. It can be successfully used with
- many types of networks including those based on various
- LAN media, and wide area networks. XNETMON has been
- used with multiprotocol devices including those which
- support TCP/IP, DECnet, and OSI protocols. The fault
- management tool displays the map of the network confi-
- guration with node and link state indicated in one of
- several colors to indicate current status. Alarms may
- be enabled to alert the operator of events occurring in
- the network. Events are logged to disk. The confi-
- guration management tool may be used to edit the net-
- work management information base stored in the network
- management station to reflect changes occurring in the
- network. Other features include graphs and tabular
- tools for use in fault and performance management and
- mechanisms by which additional variables, such as
- vendor-specific variables, may be added. The XNETMON
- application comes complete with source code including a
- powerful set of portable libraries for generating and
- parsing SNMP messages. Output data from XNETMON may be
- transferred via flat files for additional report gen-
- eration by a variety of statistical packages.
-
- MECHANISM
- The XNETMON application is based on the Simple Network
- Management Protocol (SNMP). Polling is performed via
- the powerful SNMP get-next operator and the SNMP get
- operator. Trap directed polling is used to regulate
- the focus and intensity of the polling.
-
- CAVEATS
- None.
-
- BUGS
-
-
-
- IETF NOCTools Working Group [Page 150]
-
- Internet Tool Catalog XNETMON (II)
-
-
- None known.
-
- LIMITATIONS
- The monitored and managed nodes must implement the SNMP
- over UDP per RFC 1098 or must be reachable via a proxy
- agent.
-
- HARDWARE REQUIRED
- X windows workstation with UDP socket library. Mono-
- chrome is acceptable but color is far superior.
-
- SOFTWARE REQUIRED
- X windows version 11 release 3 or later.
-
- AVAILABILITY
- This is a commercial product available under license
- from:
-
- SNMP Research
- P.O. Box 8593
- Knoxville, TN 37996-4800
- (615) 573-1434 (Voice)
- (615) 573-9197 (FAX)
- Attn: Dr. Jeff Case
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 151]
-
- Internet Tool Catalog XNETPERFMON
-
-
- NAME
- xnetperfmon -- a graphical network performance and
- fault management tool from SNMP Research.
-
- KEYWORDS
- manager, status; DECnet, ethernet, IP, OSI, ring, star;
- NMS, SNMP, X; DOS, UNIX, VMS; sourcelib.
-
- ABSTRACT
- Xnetperfmon may be used to plot SNMP variables as a
- graphical display. These graphs are often useful for
- fault and performance management. Variables may be
- plotted as gauges versus time. Alternatively, counters
- may be plotted as delta count/delta time (rates). The
- user may easily customize the variables to be plotted,
- labels, step size, update interval, and the like. The
- scales automatically adjust whenever a point to be
- plotted would go off scale.
-
- MECHANISM
- The xnetperfmon application communicates with remote
- agents or proxy agents via the Simple Network Manage-
- ment Protocol (SNMP).
-
- CAVEATS
- All plots for a single invocation of xnetperfmon must
- be for variables provided by a single network manage-
- ment agent. However, multiple invocations of xnetperf-
- mon may be active on a single display simultaneously or
- proxy agents may be used to summarize information at a
- common point.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- Systems supporting X windows.
-
- SOFTWARE REQUIRED
- X Version 11 release 2 or later.
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 152]
-
- Internet Tool Catalog XNETPERFMON
-
-
-
- AVAILABILITY
- This is a commercial product available under license
- from:
-
- SNMP Research
- P.O. Box 8593
- Knoxville, TN 37996-4800
- (615) 573-1434 (Voice)
- (615) 573-9197 (FAX)
- Attn: Dr. Jeff Case
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 153]
-
- Internet Tool Catalog XUP
-
-
- NAME
- xup
-
- KEYWORDS
- status; ping, X; HP.
-
- ABSTRACT
- Xup uses the X-Windows to display the status of an
- "interesting" set of hosts.
-
- MECHANISM
- Xup uses ping to determine host status.
-
- CAVEATS
- Polling for status increases network load.
-
- BUGS
- None known.
-
- LIMITATIONS
- None reported.
-
- HARDWARE REQUIRED
- Runs only on HP series 300 and 800 workstations.
-
- SOFTWARE REQUIRED
- Version 10 of X-Windows.
-
- AVAILABILITY
- A standard command for the HP 300 & 800 Workstations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 154]
-
- Appendix Network Management Tutorial
-
-
- Network Management Tutorial
-
-
- This tutorial is an overview of the practice of network
- management. Reading this section is no substitute for know-
- ing your system, and knowing how it is used. Do not wait
- until things break to learn what they ought to do or how
- they usually work: a crisis is not the time for determining
- how "normal" packet traces should look. Furthermore, it
- takes little imagination to realize that you do not want to
- be digging through manuals while your boss is screaming for
- network service to be restored.
-
- We assume an acquaintance with the TCP/IP protocol suite and
- the Internet architecture. There are many available refer-
- ences on these topics, several of which are listed below in
- Section 7.
-
- Since many of the details of network management are system-
- specific, this tutorial is a bit superficial. There is,
- however, a more fundamental problem in prescribing network
- management practices: network management is not a well-
- understood endeavor. At present, the cutting edge of net-
- work management is the use of distributed systems to collect
- and exchange status information, and then to display the
- data as histograms or trend lines. It is not clear that we
- know what data should be collected, how to analyze it when
- we get it, or how to structure our collection systems. For
- now, automated, real-time control of internets is an aspira-
- tion, rather than a reality. The communications systems
- that we field are apparently more complex than we can
- comprehend, which no doubt accounts in part for their fre-
- quently surprising behavior.
-
- The first section of this tutorial lists the overall goals
- and functions of network management. It presents several
- aspects of network management, including system monitoring,
- fault detection and isolation, performance testing, confi-
- guration management, and security. These discussions are
- followed by a bibliographic section. The tutorial closes
- with some final advice for network managers.
-
- 1. Network Management Goals and Functions
-
- An organization's view of network management goals is shaped
- by two factors:
-
-
-
-
-
- IETF NOCTools Working Group [Page 155]
-
- Appendix Network Management Tutorial
-
-
-
- 1. people in the organization depend on the system
- working,
-
- 2. LANs, routers, lines, and other communications
- resources have costs.
-
- From the organizational vantage point, the ultimate goal of
- network management is to provide a consistent, predictable,
- acceptable level of service from the available data communi-
- cations resources. To achieve this, a network manager must
- first be able to perform fault detection, isolation, and
- correction. He must also be able to effect configuration
- changes with a minimum of disruption, and measure the utili-
- zation of system components.
-
- People actually managing networks have a different focus.
- Network managers are usually evaluated by the availability
- and performance of their communications systems, even though
- many factors of net performance are beyond their control.
- To them, the most important requirement of a network manage-
- ment tool is that it allows the detection and diagnosis of
- faults before users can call to complain: users (and bosses)
- can often be placated just by knowing that a network problem
- has been diagnosed. Another vital network management func-
- tion is the ability to collect data that justify current or
- future expenditures for the data communications plant and
- staff.
-
- Following a section on system monitoring, this tutorial
- addresses fault, performance, configuration, and security
- management. By fault management, we mean the detection,
- diagnosis, and correction of network malfunctions. Under
- the subject of performance management, we include support
- for predictable, efficient service, as well as capacity
- planning and capacity testing. Configuration management
- includes support for orderly configuration changes (usually,
- system growth), and local administration of component names
- and addresses. Security management includes both protecting
- system components from damage and protecting sensitive
- information from unintentional or malicious disclosure or
- corruption.
-
- Readers familiar with the ISO management standards and
- drafts will note both that we have borrowed heavily from the
- "OSI Management Framework," except that we have omitted the
- "account management" function. Account management seems a
- bit out of place with the other network management
-
-
-
- IETF NOCTools Working Group [Page 156]
-
- Appendix Network Management Tutorial
-
-
- functions. The logging required by account management is
- likely to be done by specialized, dedicated subsystems that
- are distinct from other network management components.
- Hence, this tutorial does not cover account management.
- Rest assured, however, that account management, if required,
- will be adequately supported and staffed.
-
- For those with a DoD background, security may also seem out
- of place as a subtopic of network management. Without
- doubt, communications security is an important issue that
- should be considered in its own right. Because of the
- requirements of trust for security mechanisms, security com-
- ponents will probably not be integrated subcomponents of a
- larger network management system. Nevertheless, because a
- network manager has a responsibility to protect his system
- from undue security risks, this tutorial includes a discus-
- sion on internet security.
-
- 2. System Monitoring
-
- System monitoring is a fundamental aspect of network manage-
- ment. One can divide system monitoring into two rough
- categories: error detection and baseline monitoring.
-
- System errors, such as misformatted frames or dropped pack-
- ets, are not in themselves cause for concern. Spikes in
- error rates, however, should be investigated. It is sound
- practice to log error rates over time, so that increases can
- be recognized. Furthermore, logging error rates as a func-
- tion of traffic rates can be used to detect congestion.
- Investigate unusual error rates and other anomalies as they
- are detected, and keep a notebook to record your
- discoveries.
-
- Day-to-day traffic should be monitored, so that the opera-
- tional baselines of a system and its components can be
- determined. As well as being essential for performance
- management, baseline determination and traffic monitoring
- are the keys to early fault detection.
-
- A preliminary step to developing baseline measurements is
- construction of a system map: a graphical representation of
- the system components and their interfaces. Then, measure-
- ments of utilization (i.e., use divided by capacity) are
- needed. Problems are most likely to arise, and system tun-
- ing efforts are most likely to be beneficial, at highly
- utilized components.
-
-
-
-
- IETF NOCTools Working Group [Page 157]
-
- Appendix Network Management Tutorial
-
-
- It is worthwhile to develop a source/destination traffic
- matrix, including a breakdown of traffic between the local
- system and other internet sites. Both volume and type of
- traffic should be logged, along with its evolution over
- time. Of particular interest for systems with diskless
- workstations is memory swapping and other disk server
- access. For all systems, broadcast traffic and routing
- traffic should be monitored. Sudden increases in the vari-
- ance of delay or the volume of routing traffic may indicate
- thrashing or other soft failures.
-
- In monitoring a system, long-term averages are of little
- use. Hourly averages are a better indicator of system use.
- Variance in utilization and delay should also be tracked.
- Sudden spikes in variance are tell-tale signs that a problem
- is looming or exists. So, too, are trends of increased
- packet or line errors, broadcasts, routing traffic, or
- delay.
-
- 3. Fault Detection and Isolation
-
- When a system fails, caution is in order. A net manager
- should make an attempt to diagnose the cause of a system
- crash before rebooting. In many cases, however, a quick
- diagnosis will not be possible. For some high priority
- applications, restoring at least some level of service will
- have priority over fault repair or even complete fault diag-
- nosis. This necessitates prior planning. A net manager
- must know the vital applications at his site. If applica-
- tions require it, he must also have a fall-back plan for
- bringing them online. Meanwhile, repeated crashes or
- hardware failures are unambiguous signs of a problem that
- must be corrected.
-
- A network manager should prepare for fault diagnosis by
- becoming familiar with how diagnostic tools respond to net-
- work failure. In times of relative peace, a net manager
- should occasionally unplug the network connection from an
- unused workstation and then "debug" the problem.
-
- When diagnosing a fault or anomaly, it is vital to proceed
- in an orderly manner, especially since network faults will
- usually generate spurious as well as accurate error mes-
- sages. Remember to keep in mind that the network itself is
- failing. Do not place too much trust in anything obtained
- remotely. Furthermore, it is unlikely to be significant
- that remote information such as DNS names or NFS files can-
- not be obtained.
-
-
-
- IETF NOCTools Working Group [Page 158]
-
- Appendix Network Management Tutorial
-
-
- Even spurious messages can be revealing, because they pro-
- vide clues to the problem. From the data at hand, develop
- working hypotheses about probable causes of the problems you
- detect. Direct your further data gathering efforts so that
- the information you get will either refute or support your
- hypotheses.
-
- An orderly approach to debugging is facilitated if it is
- guided by a model of network behavior. The following por-
- tions of this section present such a model, along with a
- procedure for checking network connectivity. The section
- concludes with some hints for diagnosing a particularly
- tricky class of connectivity problem.
-
- 3.1 A Network Model as a Diagnostic Framework
-
- The point of having a model of how things work is to have a
- basis for developing educated guesses about how things go
- wrong. The problem of cascading faults -- faults generating
- other faults -- makes use of a conceptual model a virtual
- necessity.
-
- In general, only problems in a component's hardware or
- operating system will generate simultaneous faults in multi-
- ple protocol layers. Otherwise, faults will propagate vert-
- ically (up the protocol stack) or horizontally (between
- peer-level communications components). Applying a concep-
- tual model that includes the architectural relations of net-
- work components can help to order an otherwise senseless
- barrage of error messages and symptoms.
-
- The model does not have to be formal or complex to bring
- structure to debugging efforts. A useful start is something
- as simple as the following:
-
- 1. Applications programs use transport services:
- TCP/UDP. Before using service, applications that
- accept host names as parameters must translate the
- names into IP addresses. Translation may be based
- on a static table lookup (/etc/hosts file in UNIX
- hosts), the DNS, or yellow pages. Nslookup and
- DiG are tools for monitoring the activities of the
- DNS.
-
- 2. Transport protocol implementations use IP ser-
- vices. The local IP module makes the initial
- decision on forwarding. An IP datagram is for-
- warded directly to the destination host if the
-
-
-
- IETF NOCTools Working Group [Page 159]
-
- Appendix Network Management Tutorial
-
-
- destination is on the same network as the source.
- Otherwise, the datagram is forwarded to a gateway
- attached to the network. On BSD hosts, the con-
- tents of a host's routing table are visible by use
- of the "netstat" command.*
-
- 3. IP implementations translate the IP address of a
- datagram's next hop (either the destination host
- or a gateway) to a local network address. For
- ethernets, the Address Resolution Protocol (ARP)
- is commonly used for this translation. On BSD
- systems, an interface's IP address and other con-
- figuration options can be viewed by use of the
- "ifconfig" command, while the contents of a host's
- ARP cache may be viewed by use of "arp" command.
-
- 4. IP implementations in hosts and gateways route
- datagrams based on subnet and net identifiers.
- Subnetting is a means of allocating and preserving
- IP address space, and of insulating users from the
- topological details of a multi-network campus.
- Sites that use subnetting reserve portions of the
- IP address's host identifier to indicate particu-
- lar networks at their campus. Subnetting is
- highly system-dependent. The details are a criti-
- cal, though local, issue. As for routing between
- separate networks, a variety of gateway-to-gateway
- protocols are used. Traceroute is a useful tool
- for investigating routing problems. The tool,
- "query," can be used to examine RIP routing
- tables.
-
- A neophyte network manager should expand the above descrip-
- tion so that it accurately describes his particular system,
- _________________________
- * Initial forwarding may actually be complex and
- vulnerable to multiple points of failure. For example,
- when sending an IP datagram, 4.3BSD hosts first look
- for a route to the particular host. If none has been
- specified for the destination, then a search is made
- for a route to the network of the destination. If this
- search also fails, then as a last resort, a search is
- made for a route to a "default" gateway. Routes to
- hosts, networks, and the "default" gateway may be stat-
- ic, loaded at boot time and perhaps updated by operator
- commands. Alternatively, they may be dynamic, loaded
- from redirects and routing protocol updates.
-
-
-
-
- IETF NOCTools Working Group [Page 160]
-
- Appendix Network Management Tutorial
-
-
- and learn the tools and techniques for monitoring the opera-
- tions at each of the above stages.
-
- 3.2 A Simple Procedure for Connectivity Check
-
- In this section, we describe a procedure for isolating a
- TCP/IP connectivity problem.** In this procedure, a series
- of tests methodically examine connectivity from a host,
- starting with nearby resources and working outward. The
- steps in our connectivity-testing procedure are:
-
- 1. As an initial sanity check, ping your own IP address
- and the loopback address.
-
- 2. Next, try to ping other IP hosts on the local subnet.
- Use numeric addresses when starting off, since this
- eliminates the name resolvers and host tables as poten-
- tial sources of problems. The lack of an answer may
- indicate either that the destination host did not
- respond to ARP (if it is used on your LAN), or that a
- datagram was forwarded (and hence, the destination IP
- address was resolved to a local media address) but that
- no ICMP Echo Reply was received. This could indicate a
- length-related problem, or misconfigured IP Security.
-
- 3. If an IP router (gateway) is in the system, ping both
- its near and far-side addresses.
-
- 4. Make sure that your local host recognizes the gateway
- as a relay. (For BSD hosts, use netstat.)
-
- 5.addresses
- Still using numeric IP addresses, try to ping hosts
- beyond the gateway. If you get no response, run hop-
- check or traceroute, if available. Note whether your
- packets even go to the gateway on their way to the des-
- tination. If not, examine the methods used to instruct
- your host to use this gateway to reach the specified
- destination net (e.g., is the default route in place?
- Alternatively, are you successfully wire-tapping the
- IGP messages broadcast on the net you are attached to?)
-
- _________________________
- ** Thanks to James VanBokkelen, president of FTP
- Software, for sharing with us a portion of a PC/TCP
- support document, the basis for the above connectivity
- procedure.
-
-
-
-
- IETF NOCTools Working Group [Page 161]
-
- Appendix Network Management Tutorial
-
-
- If traceroute is not available, ping, netstat, arp, and
- a knowledge of the IP addresses of all the gateway's
- interfaces can be used to isolate the cause of the
- problem. Use netstat to determine your next hop to the
- destination. Ping that IP address to ensure the router
- is up. Next, ping the router interface on the far sub-
- net. If the router returns "network unreachable" or
- other errors, investigate the router's routing tables
- and interface status. If the pings succeed, ping the
- close interface of the succeeding next hop gateway, and
- so on. Remember the routing along the outbound and
- return paths may be different.
-
- 6. Once ping is working with numeric addresses, use ping
- to try to reach a few remote hosts by name. If ping
- fails when host names are used, check the operation of
- the local name-mapping system (i.e., with nslookup or
- DiG). If you want to use "shorthand" forms ("myhost"
- instead of "myhost.mydomain.com"), be sure that the
- alias tables are correctly configured.
-
- 7. Once basic reachability has been established with ping,
- try some TCP-based applications: FTP and TELNET are
- supported on almost all IP hosts, but FINGER is a
- simpler protocol. The Berkeley-specific protocols
- (RSH, RCP, REXEC and LPR) require extra configuration
- on the server host before they can work, and so are
- poor choices for connectivity testing.
-
- If problems arise in steps 2-7 above, rerunning the tests
- while executing a line monitor (e.g., etherfind, netwatch,
- or tcpdump) can help to pinpoint the problem.
-
- The above procedure is sound and useful, especially if lit-
- tle is known about the cause of the connectivity problem.
- It is not, however, guaranteed to be the shortest path to
- diagnosis. In some cases, a binary search on the problem
- might be more effective (i.e., try a test "in the middle,"
- in a spot where the failure modes are well defined). In
- other cases, available information might so strongly suggest
- a particular failure that immediately testing for it is in
- order. This last "approach," which might be called "hunting
- and pecking," should be used with caution: chasing one will
- o' the wisp after another can waste much time and effort.
-
- Note that line problems are still among the most common
- causes of connectivity loss. Problems in transmission
- across local media are outside the scope of this tutorial.
-
-
-
- IETF NOCTools Working Group [Page 162]
-
- Appendix Network Management Tutorial
-
-
- But, if a host or workstation loses or cannot establish con-
- nectivity, check its physical connection.
-
- 3.3 Limited Connectivity
-
- An interesting class of problems can result in a particu-
- larly mysterious failure: TELNET or other low-volume TCP
- connections work, but large file transfers fail. FTP
- transfers may start, but then hang. There are several pos-
- sible culprits in this problem. The most likely suspects
- are IP implementations that cannot fragment or reassemble
- datagrams, and TCP implementations that do not perform
- dynamic window sizing (a.k.a. Van Jacobson's "Slow Start"
- algorithm). Another possibility is mixing incompatible
- frame formats on an ethernet.
-
- Even today, some IP implementations in the Internet cannot
- correctly handle fragmentation or reassembly. They will
- work fine for small packets, but drop all large packets.
-
- The problem can also be caused by buffer exhaustion at gate-
- ways that connect interfaces of widely differing bandwidth.
- Datagrams from a TCP connection that traverses a bottleneck
- will experience queue delays, and will be dropped if buffer
- resources are depleted. The congestion can be made worse if
- the TCP implementation at the traffic source does not use
- the recommended algorithms for computing retransmission
- times, since spuriously retransmitted datagrams will only
- add to the congestion.* Fragmentation, even if correctly
- implemented, will compound this problem, since processing
- delays and congestion will be increased at the bottleneck.
-
- Serial Line Internet Protocol (SLIP) links are especially
- vulnerable to this and other congestion problems. SLIP
- lines are typically an order of magnitude slower than other
- gateway interfaces. Also, the SLIP lines are at times con-
- figured with MTUs (Maximum Transfer Unit, the maximum length
- of an IP datagram for a particular subnet) as small as 256
- _________________________
- * To avoid this problem, TCP implementations on the In-
- ternet must use "exponential backoff" between succes-
- sive retransmissions, Karn's algorithm for filtering
- samples used to estimate round-trip delay between TCP
- peers, and Jacobson's algorithm for incorporating vari-
- ance into the "retransmission time-out" computation for
- TCP segments. See Section 4.2.3.1 of RFC 1122, "Re-
- quirements for Internet Hosts -- Communication Layers."
-
-
-
-
- IETF NOCTools Working Group [Page 163]
-
- Appendix Network Management Tutorial
-
-
- bytes, which virtually guarantees fragmentation.
-
- To alleviate this problem, TCP implementations behind slow
- lines should advertise small windows. Also, if possible,
- SLIP lines should be configured with an MTU no less than 576
- bytes. The tradeoff to weigh is whether interactive traffic
- will be penalized too severly by transmission delays of
- lengthy datagrams from concurrent file transfers.
-
- Misuse of ethernet trailers can also cause the problem of
- hanging file transfers. "Trailers" refers to an ethernet
- frame format optionally employed by BSD systems to minimize
- buffer copying by system software. BSD systems with ether-
- net interfaces can be configured to send large frames so
- that their address and control data are at the end of a
- frame (hence, a "trailer" instead of a "header"). After a
- memory page is allocated and loaded with a received ethernet
- frame, the ethernet data will begin at the start of the
- memory page boundary. Hence, the ethernet control informa-
- tion can be logically stripped from the end merely by
- adjusting the page's length field. By manipulating virtual
- memory mapping, this same page (sans ethernet control infor-
- mation), can then be passed to the local IP module without
- additional allocation and loading of memory. The disadvan-
- tage in using trailers is that it is non-standard. Many
- implementations cannot parse trailers.
-
- The hanging FTP problem will appear if a gateway is not con-
- figured to recognize trailers, but a host or gateway immedi-
- ately "upstream" on an ethernet uses them. Short datagrams
- will not be formatted with trailers, and so will be pro-
- cessed correctly. When the bulk data transfer starts, how-
- ever, full-sized frames will be sent, and will use the
- trailer format. To the gateway that receives them, they
- appear simply as misformatted frames, and are quietly
- dropped. The solution, obviously, is to insure that all
- hosts and gateways on an ethernet are consistent in their
- use of trailers. Note that RFC 1122, "Internet Host
- Requirements," places very strict restrictions on the use of
- trailers.
-
- 4. Performance Testing
-
- Performance management encompasses two rather different
- activities. One is passive system monitoring to detect
- problems and determine operational baselines. The goal is
- to measure system and component utilization and so locate
- bottlenecks, since bottlenecks should receive the focus of
-
-
-
- IETF NOCTools Working Group [Page 164]
-
- Appendix Network Management Tutorial
-
-
- performance tuning efforts. Also, performance data is usu-
- ally required by upper level management to justify the costs
- of communications systems. This is essentially identical to
- system monitoring, and is addressed at greater length in
- Section 2, above.
-
- Another aspect of performance management is active perfor-
- mance testing and capacity planning. Some work in this area
- can be based on analysis. For example, a rough estimate of
- gateway capacity can be deduced from a simple model given by
- Charles Hedrick in his "Introduction to Administration of an
- Internet-based Local Network," which is
-
- per-packet processing time =
- switching time +
- (packet size) * (transmission bps).
-
- Another guideline for capacity planning is that in order to
- avoid excessive queuing delays, a system should be sized at
- about double its expected load. In other words, system
- capacity should be so high that utilization is no greater
- than 50%.
-
- Although there are more sophisticated analytic models of
- communications systems than those above, their added com-
- plexity does not usually gain a corresponding accuracy.
- Most analytic models of communications nets require assump-
- tions about traffic load distributions and service rates
- that are not merely problematic, but are patently false.
- These errors tend to result in underestimating queuing
- delays. Hence, it is often necessary to actually load and
- measure the performance of a real communications system if
- one is to get accurate performance predictions. Obviously,
- this type of testing is performed on isolated systems or
- during off hours. The results can be used to evaluate
- parameter settings or predict performance during normal
- operations.
-
- Simulations can be used to supplement the testing of real
- systems. To be believable, however, simulations require
- validation, which, in turn, requires measurements from a
- real system. Whether testing or simulating a system's per-
- formance, actual traffic traces should be incorporated as
- input to traffic generators. The performance of a communi-
- cations system will be greatly influenced by its load
- characteristics (burstiness, volume, etc.), which are them-
- selves highly dependent on the applications that are run.
-
-
-
-
- IETF NOCTools Working Group [Page 165]
-
- Appendix Network Management Tutorial
-
-
- When tuning a net, in addition to the usual configuration
- parameters, consider the impact of the location of gateways
- and print and file servers. A few rules of thumb can guide
- the location of shared system resources. First, there is
- the principle of locality: a system will perform better if
- most traffic is between nearby destinations. The second
- rule is to avoid creating bottlenecks. For example, multi-
- ple diskservers may be called for to support a large number
- of workstations. Furthermore, to avoid LAN and diskserver
- congestion, workstations should be configured with enough
- memory to avoid frequent swapping.
-
- As a final note on performance management, proceed cau-
- tiously if your ethernet interface allows you to customize
- its collision recovery algorithm. This is almost always a
- bad idea. The best that it can accomplish is to give a few
- favored hosts a disproportionate share of the ethernet
- bandwidth, perhaps at the cost of a reduction in total sys-
- tem throughput. Worse, it is possible that differing colli-
- sion recovery algorithms may exhibit a self-synchronizing
- behavior, so that excess collisions are generated.
-
- 5. Configuration Management
-
- Configuration management is the setting, collecting, and
- storing of the state and parameters of network resources.
- It overlaps all other network management functions. Hence,
- some aspects of configuration management have already been
- addressed (e.g., tuning for performance). In this section,
- we will focus on configuration management activities needed
- to "hook up" a net or campus to a larger internet. We will
- not, of course, include specific details on installing or
- maintaining internetted communications systems. We will,
- however, skim over some of the TCP/IP configuration
- highlights.
-
- Configuration management includes "name management" -- the
- control and allocation of system names and addresses, and
- the translation between names and addresses. Name-to-
- address translation is performed by "name servers." We con-
- clude this section with a few strictures on the simultaneous
- use of two automated name-servers, the Domain Name System
- (DNS), and Yellow Pages (YP).
-
- 5.1 Required Host Configuration Data for TCP/IP internets
-
- In a TCP/IP internet, each host needs several items of
- information for internet communications. Some will be
-
-
-
- IETF NOCTools Working Group [Page 166]
-
- Appendix Network Management Tutorial
-
-
- host-specific, while other information will be common for
- all hosts on a subnet. In a soon to be published RFC docu-
- ment,* R. Droms identifies the following configuration data
- required by internet hosts:
-
- o+ An IP address, a host specific value that can be
- hard-coded or obtained via BOOTP, the Reverse
- Address Resolution Protocol (RARP) or Dynamic RARP
- (DRARP).
-
- o+ Subnet properties, such as the subnet mask and the
- Maximum Transmission Unit (MTU); obviously, these
- values are not host-specific.
-
- o+ Addresses of "entry" gateways to the internet;
- addresses of default gateways are usually hard-
- coded; though the ICMP "redirect" message can be
- used to refine a host's routing tables, there is
- currently no dynamic TCP/IP mechanism or protocol
- for a host to locate a gateway; an IETF working
- group is busy on this problem.
-
- o+ For hosts in internets using the Domain Name Sys-
- tem (DNS) for name-to-address translation, the
- location of a local DNS server is needed; this
- information is not host-specific, and usually
- hard-coded;
-
- o+ Host name (domain name, for hosts using DNS);
- obviously host-specific; either hard-coded or
- obtained in a boot procedure.
-
- o+ For diskless hosts, various boot services. BOOTP
- is the standard Internet protocol for downloading
- boot configuration information. The Trivial File
- Transfer Protocol (TFTP) is typically used for
- downloading boot images. Sun computers use the
- "bootparams" RPC mechanism for downloading initial
- configuration data to a host.
-
- There are ongoing developments, most notably the work of the
- Dynamic Host Configuration Working Group of the IETF, to
- support dynamic, automatic gathering of the above data. In
- the meantime, most systems will rely on hand-crafted confi-
- guration files.
- _________________________
- * Draft "Dynamic Configuration of Internet Hosts."
-
-
-
-
- IETF NOCTools Working Group [Page 167]
-
- Appendix Network Management Tutorial
-
-
- 5.3 Connecting to THE Internet
-
- The original TCP/IP Internet (spelled with an upper-case
- "I") is still active, and still growing. An interesting
- aspect of the Internet is that it spans many independently
- administered systems.
-
- Connection to the Internet requires: a registered network
- number, for use in IP addresses; a registered autonomous
- system number (ASN), for use in internet routing; and, a
- registered domain name. Fielding a primary and backup DNS
- server is a condition for registering a domain name.
-
- The Defense Data Network (DDN) Network Information Center
- (NIC) is responsible for registering network numbers, auto-
- nomous system numbers, and domain names. Regional nets will
- have their own policies and requirements for Internet con-
- nections, but all use the NIC for this registration service.
- Contact the NIC for further information, at:
-
- DDN Network Information Center
- SRI International, Room EJ291
- 333 Ravenswood Avenue
- Menlo Park, CA 94025
-
- Email: HOSTMASTER@NIC.DDN.MIL
- Phone: 1-415-859-3695
- 1-800-235-3155 (toll-free hotline)
-
- 5.4 YP and DNS: Dueling name servers.
-
- The Domain Name System (DNS) provides name service: it
- translates host names into IP addresses (this mapping is
- also called "resolution"). Two widespread DNS implementa-
- tions are "bind" and "named." The Sun Yellow Pages (YP)
- system can be configured to provide an identical service, by
- providing remote, keyed access to the "hosts.byname" map.
- Unfortunately, if both DNS and the YP hosts.byname map are
- installed, they can interact in disruptive ways.
-
- The problem has been noted in systems in which DNS is used
- as a fallback, to resolve hostnames that YP cannot. If DNS
- is slow in responding, the timeout in program ypserv may
- expire, which triggers a repeated request. This can result
- in disaster if DNS was initially slow because of congestion:
- the slower things get, the more requests are generated,
- which slows things even more. A symptom of this problem is
- that failures by the DNS server or network will trigger
-
-
-
- IETF NOCTools Working Group [Page 168]
-
- Appendix Network Management Tutorial
-
-
- numerous requests to DNS.
-
- Reportedly, the bug in YP that results in the avalanche of
- DNS requests has been repaired in SunOS 4.1. The problem,
- however, is more fundamental than an implementation error.
- The YP map hosts.byname and the DNS contain the same class
- of information. One can get an answer to the same query
- from each system. These answers may well be different:
- there is not a mechanism to maintain consistency between the
- systems. More critical, however, is the lack of a mechanism
- or procedure to establish which system is authoritative.
- Hence, running the DNS and YP name services in parallel is
- pointless. If the systems stay consistent, then only one is
- needed. If they differ, there is no way to choose which is
- correct.
-
- The YP hosts.byname service and DNS are comparable, but
- incompatible. If possible, a site should not run both ser-
- vices. Because of Internet policy, sites with Internet con-
- nections MUST use the DNS. If YP is also used, then it
- should be configured with YP-to-DNS disabled.
-
- Hacking a system so that it uses DNS rather than the YP
- hosts.byname map is not trivial, and should not be attempted
- by novices. The approach is to rebuild the shared C link-
- library, so that system calls to gethostbyname() and
- gethostbyaddr() will use DNS rather than YP. To complete
- the change, programs that do not dynamically link the shared
- C library (rcp, arp, etc.) must also be rebuilt.
-
- Modified shared C libraries for Sun 3s and Sun 4s are avail-
- able via anonymous FTP from host uunet.uu.net, in the sun-
- fixes directory. Note that use of DNS routines rather than
- YP for general name resolution is not a supported SunOS
- feature at this time.
-
- 6. Internet Security
-
- The guidelines and advice in this section pertain to enhanc-
- ing the protection of data that are merely "sensitive." By
- themselves, these measures are insufficient for protecting
- "classified" data. Implementing the policies required to
- protect classified data is subject to stringent, formal
- review procedures, and is regulated by agencies such as the
- Defense Investigative Service (DIS) and the National Secu-
- rity Agency (NSA).
-
- A network manager must realize that he is responsible for
-
-
-
- IETF NOCTools Working Group [Page 169]
-
- Appendix Network Management Tutorial
-
-
- protecting his system and its users. Furthermore, though
- the Internet may appear to be a grand example of a coopera-
- tive joint enterprise, recent incidents have made it clear
- that not all Internet denizens are benign.
-
- A network manager should be aware that the network services
- he runs have a large impact on the security risks to which
- his system is exposed. The prudent network manager will be
- very careful as to what services his site provides to the
- rest of the Internet, and what access restrictions are
- enforced. For example, the protocol "finger" may provide
- more information about a user than should be given to the
- world at large. Worse, most implementations of the protocol
- TFTP give access to all world-readable files.
-
- This section highlights several basic security considera-
- tions for Internet sites. It then lists several sources of
- information and advice on improving the security of systems
- connected to the Internet.
-
- 6.1 Basic Internet Security
-
- Two major Internet security threats are denial of service
- and unauthorized access.
-
- Denial of service threats often take the form of protocol
- spoofers or other malicious traffic generators. These prob-
- lems can be detected through system monitoring logs. If an
- attack is suspected, immediately contact your regional net
- office (e.g., SURANET, MILNET). In addition, DDN users
- should contact SCC, while other Internet users should con-
- tact CERT (see below). A cogent description of your
- system's symptoms will be needed.
-
- At your own site, be prepared to isolate the problems (e.g.,
- by limiting disk space available to the message queue of a
- mail system under attack). As a last resort, coping with an
- attack may require taking down an Internet connection. It
- is better, however, not to be too quick to quarantine your
- site, since information for coping with the attack may come
- via the Internet.
-
- Unauthorized access is a potentially more ominous security
- threat. The main avenues are attacks against passwords and
- attacks against privileged system processes.
-
- An appallingly common means of gaining entry to systems is
- by use of the initial passwords to root, sysdiag, and other
-
-
-
- IETF NOCTools Working Group [Page 170]
-
- Appendix Network Management Tutorial
-
-
- management accounts that systems are shipped with. Only
- slightly less vulnerable are common or trivial passwords,
- since these are readily subverted by dictionary attacks.*
- Obvious steps can reduce the risk of password attacks: pass-
- words should be short-lived, at least eight characters long,
- with a mix of upper and lower case, and preferably random.
- The distasteful aspect of memorizing a random string can be
- alleviated if the password is pronounceable.
-
- Improving passwords does not remove all risks. Passwords
- transmitted over an ethernet are visible to all attached
- systems. Furthermore, gateways have the potential to inter-
- cept passwords used by any FTP or TELNET connections that
- traverse them. It is a bad idea for the root account to be
- accessed by FTP or TELNET if the connections must cross
- untrusted elements.
-
- Attacks against system processes are another avenue of unau-
- thorized access. The principle is that by subverting a sys-
- tem process, the attacker can then gain its access
- privileges.
-
- One approach to reducing this risk is to make system pro-
- grams harder to subvert. For example, the widespread attack
- in November 1988 by a self-replicating computer program
- ("worm," analogous to a tapeworm) subverted the "fingerd"
- process, by loading an intrusive bootstrap program (known
- variously as a "grappling hook" or "vector" program), and
- then corrupting the stack space so that a subroutine's
- return address was overwritten with the address of the
- bootstrap program.** The security hole in fingerd consisted
- of an input routine that did not have a length check. Secu-
- rity fixes to "fingerd" include the use of a revised input
- routine.
-
- A more general protection is to apply the principle of
- "least privilege." Where possible, system routines should
- run under separate user IDs, and should have no more
- privilege than is necessary for them to function.
- _________________________
- * Exotic fantasy creatures and women's names are well
- represented in most password dictionaries.
- ** An early account of the Internet Worm incident of
- November 1988 is given by Eugene Spafford in the Janu-
- ary 89 issue of "Computer Communications Review."
- Several other articles on the worm incident are in the
- June 89 issue of the "Communications of the ACM."
-
-
-
-
- IETF NOCTools Working Group [Page 171]
-
- Appendix Network Management Tutorial
-
-
- To further protect against attacks on system processes, sys-
- tem managers should regularly check their system programs to
- ensure that they have not been tampered with or modified in
- any way. Checksums should be used for this purpose. Using
- the operating system to check a file's last date of modifi-
- cation is insufficient, since the date itself can be
- compromised.
-
- Finally, to avoid the unauthorized replacement of system
- code, care should be exercised in assigning protection to
- its directory paths.
-
- Some system programs actually have "trap doors" that facili-
- tate subversion. A trap door is the epitome of an undocu-
- mented feature: it is a hidden capability of a system pro-
- gram that allows a knowledgeable person to gain access to a
- system. The Internet Worm exploited what was essentially a
- trap door in the BSD sendmail program.
-
- Ensuring against trap doors in software as complex as send-
- mail may be infeasible. In an ideal world, the BSD sendmail
- program would be replaced by an entire mail subsystem (i.e.,
- perhaps including mail user agents, mail transfer agents,
- and text preparation and filing programs). Any site using
- sendmail should at least obtain the less vulnerable,
- toughened distribution from ucbarpa.berkeley.edu, in file
- ~ftp/4.3/sendmail.tar.Z. Sites running SunOS should note
- that the 4.0.3 release closed the security holes exploited
- by the Internet Worm. Fixes for a more obscure security
- hole in SunOS are available from host uunet.uu.net in
- ~ftp/sun-fixes; these improvements have been incorporated in
- SunOS 4.1.
-
- Sendmail has problems other than size and complexity. Its
- use of root privileges, its approach to alias expansion, and
- several other design characteristics present potential ave-
- nues of attack. For UNIX sites, an alternative mail server
- to consider is MMDF, which is now at version 2. MMDF is
- distributed as part of the SCO UNIX distribution, and is
- also available in the user contributed portion of 4.3BSD.
- Though free, MMDF is licensed, and resale is restricted.
- Sites running MMDF should be on the mmdf email list;
- requests to join this list should be sent to:
- mmdf2-request@relay.cs.net.
-
- Programs that masquerade as legitimate system code but which
- contain trap doors or other aides to unauthorized access are
- known as trojan horses. Computer "viruses," intrusive
-
-
-
- IETF NOCTools Working Group [Page 172]
-
- Appendix Network Management Tutorial
-
-
- software that infects seemingly innocent programs and pro-
- pagates when the infected programs are executed or copied,
- are a special case of trojan horse programs.*
-
- To guard against trojan horse attacks, be wary of programs
- downloaded from remote sources. At minimum, do not download
- executables from any but the most trusted sources. Also, as
- noted above, to avoid proliferation of "infected" software,
- checksums should be computed, recorded, and periodically
- verified.
-
- 6.2 Security Information Clearing-Houses
-
- The Internet community can get security assistance from the
- Computer Emergency Response Team (CERT), established by
- DARPA in November 1988. The Coordination Center for the
- CERT (CERT/CC) is located at the Software Engineering Insti-
- tute at Carnegie Mellon University. The CERT is intended to
- respond to computer security threats such as the November
- '88 worm attack that invaded many defense and research com-
- puters. Consult RFC 1135 (Reynolds, J., "The Helminthiasis
- of the Internet", USC/ISI, December 1989), for further
- information.
-
- CERT assists Internet sites in response to security attacks
- or other emergency situations. It can immediately tap
- experts to diagnose and solve the problems, as well as
- establish and maintain communications with the affected com-
- puter users and with government authorities as appropriate.
- Specific responses will be taken in accordance with the
- nature of the problem and the magnitude of the threat.
-
- CERT is also an information clearing-house for the identifi-
- cation and repair of security vulnerabilities, informal
- assessments of existing systems in the research community,
- improvement to emergency response capability, and both ven-
- dor and user security awareness. This security information
- is distributed by periodic bulletins, and is posted to the
- USENET news group comp.security.announce. In addition, the
- security advisories issued by CERT, as well as other useful
- security-related information, are available via anonymous
- FTP from cert.sei.cmu.edu.
-
- For immediate response to attacks or incidents, CERT mans a
- _________________________
- * Virus attacks have been seen against PCs, but as yet
- have rarely been directed agains UNIX systems.
-
-
-
-
- IETF NOCTools Working Group [Page 173]
-
- Appendix Network Management Tutorial
-
-
- 24-hour hotline at (412) 268-7090. To subscribe to CERT's
- security announcement bulletin, or for further information,
- contact:
-
- CERT
- Software Engineering Institute
- Carnegie Mellon University
- Pittsburgh, PA 15213-3890
-
- (412) 268-7080
- cert@cert.sei.cmu.edu.
-
- For DDN users, the Security Coordination Center (SCC) serves
- a function similar to CERT. The SCC is the DDN's clearing-
- house for host/user security problems and fixes, and works
- with the DDN Network Security Officer. The SCC also distri-
- butes the DDN Security Bulletin, which communicates informa-
- tion on network and host security exposures, fixes, and con-
- cerns to security and management personnel at DDN facili-
- ties. It is available online, via kermit or anonymous FTP,
- from nic.ddn.mil, in SCC:DDN-SECURITY-yy-nn.TXT (where "yy"
- is the year and "nn" is the bulletin number). The SCC pro-
- vides immediate assistance with DDN-related host security
- problems; call (800) 235-3155 (6:00 a.m. to 5:00 p.m.
- Pacific Time) or send e-Mail to SCC@NIC.DDN.MIL. For 24
- hour coverage, call the MILNET Trouble Desk (800) 451-7413
- or AUTOVON 231-1713.
-
- The CERT/CC and the SCC communicate on a regular basis and
- support each other when problems occur. These two organiza-
- tions are examples of the incident response centers that are
- forming; each serving their own constituency or focusing on
- a particular area of technology.
-
- Other network groups that discuss security issues are:
- comp.protocols.tcp-ip, comp.virus (mostly PC-related, but
- occasionally covers Internet topics), misc.security, and the
- BITNET Listserv list called VIRUS-L.
-
- 7. Internet Information
-
- There are many available references on the TCP/IP protocol
- suite, the internet architecture, and the DDN Internet. A
- soon to be published FYI RFC document, "Where to Start: A
- Bibliography of General Internetworking Information." pro-
- vides a bibliography of online and hard copy documents,
- reference materials, and multimedia training tools that
- address general networking information and "how to use the
-
-
-
- IETF NOCTools Working Group [Page 174]
-
- Appendix Network Management Tutorial
-
-
- Internet." It presents a representative collection of
- materials that will help the reader become familiar with the
- concepts of internetworking. Inquires on the current status
- of this document can be sent to user-doc@nnsc.nsf.net or by
- postal mail to:
-
- Corporation for National Research Initiatives
- 1895 Preston White, Suite 100
- Reston, VA 22091
- Attn: IAB Secretariat.
-
- Two texts on networking are especially noteworthy. _I_n_t_e_r_-
- _n_e_t_w_o_r_k_i_n_g _W_i_t_h _T_C_P/_I_P, by Douglas Comer, is an informative
- description of the TCP/IP protocol suite and its underlying
- architecture. The _U_N_I_X _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n _H_a_n_d_b_o_o_k, by
- Nemeth, Snyder, and Seebass, is a "must have" for system
- administrators who are responsible for UNIX hosts. In addi-
- tion to covering UNIX, it provides a wealth of tutorial
- material on networking, the Internet, and network manage-
- ment.
-
- A great deal of information on the Internet is available
- online. An automated, online reference service is available
- from CSNET. To obtain a bibliography of their online offer-
- ings, send the email message
-
- request: info
- topic: help
- request: end
-
- to info-server@sh.cs.net.
-
- The DDN NIC also offers automated access to many NIC docu-
- ments, online files, and WHOIS information via electronic
- mail. To use the service, send an email message with your
- request specified in the SUBJECT field of the message. For
- a sampling of the type of offerings available through this
- service, send the following message
-
- To: SERVICE@NIC.DDN.MIL
- Subject: help
- Msg: <none>
-
-
- The DDN Protocol Implementations and Vendors Guide, pub-
- lished by the DDN Network Information Center (DDN NIC),* is
- _________________________
- * Products mentioned in the guide are not specifically
-
-
-
- IETF NOCTools Working Group [Page 175]
-
- Appendix Network Management Tutorial
-
-
- an online reference to products and implementations associ-
- ated with the DoD Defense Data Network (DDN) group of com-
- munication protocols, with emphasis on TCP/IP and OSI proto-
- cols. It contains information on protocol policy and
- evaluation procedures, a discussion of software and hardware
- implementations, and analysis tools with a focus on protocol
- and network analyzers. To obtain the guide, invoke FTP at
- your local host and connect to host NIC.DDN.MIL (internet
- address 26.0.0.73 or 10.0.0.51). Log in using username
- 'anonymous' with password 'guest' and get the file
- NETINFO:VENDORS-GUIDE.DOC.
-
- The DDN Protocol Guide is also available in hardcopy form.
- To obtain a hardcopy version of the guide, contact the DDN
- Network Information Center:
-
- By U.S. mail:
- SRI International
- DDN Network Information Center
- 333 Ravenswood Avenue, Room EJ291
- Menlo Park, CA 94025
-
- By e-mail:
- NIC@NIC.DDN.MIL
-
- By phone:
- 1-415-859-3695
- 1-800-235-3155 (toll-free hotline)
-
- For further information about the guide, or for information
- on how to list a product in a subsequent edition of the
- guide, contact the DDN NIC.
-
- There are many additional online sources on Internet Manage-
- ment. RFC 1118, "A Hitchhiker's Guide to the Internet," by
- Ed Krol, is a useful introduction to the Internet routing
- algorithms. For more of the nitty-gritty on laying out and
- configuring a campus net, see Charles Hedrick's "Introduc-
- tion to Administration of an Internet-based Local Network,"
- available via anonymous FTP from cs.rutgers.edu (sometimes
- listed in host tables as aramis.rutgers.edu), in subdirec-
- tory runet, file tcp-ip-admin. Finally, anyone responsible
- for systems connected to the Internet must be thoroughly
- versed in the Host Requirements RFCs (RFC 1122 and RFC 1123)
- _________________________
- endorsed or recommended by the Defense Communications
- Agency (DCA).
-
-
-
-
- IETF NOCTools Working Group [Page 176]
-
- Appendix Network Management Tutorial
-
-
- and "Requirements for Internet Gateways," RFC 1009.
-
- 8. The Final Words on Internet Management
-
- Keep smiling, no matter how bad things may seem. You are
- the expert. They need you.
-
- 9. Security Considerations
-
- Security issues are discussed in Section 6.
-
- 10. Author's Address
-
- Robert H. Stine
- SPARTA, Inc.
- 7926 Jones Branch Drive
- Suite 1070
- McLean, VA 22102
-
- EMail: STINE@SPARTA.COM
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- IETF NOCTools Working Group [Page 177]
-